Servidors intermediaris

Una xarxa informàtica pot arribar a assolir un nivell de complexitat que faci que la seva gestió i manteniment es converteixi en un problema. Quan s’arriba a aquesta situació, la persona responsable de la xarxa ha de buscar solucions, ja que si no ho redreça pot esdevenir un caos organitzatiu. La utilització de màquines amb funcions específiques de centralització de gestions, capaces d’assumir determinades funcions abans encarregades a equips de xarxa sobrecarregats, és una solució molt interessant.

Un servidor intermediari és un programa o un equip capaç d’assumir les funcions d’un altre equip.

La figura mostra un servidor intermediari en una xarxa petita. No és necessari treballar amb una gran estructura o una xarxa molt complexa per utilitzar un servidor intermediari. De servidors intermediaris n’hi ha diversos tipus.

Figura Servidor intermediari en una xarxa petita

Les funcions més habituals d’un servidor intermediari són controlar l’accés a serveis o a recursos, proporcionar memòria cau per a determinats serveis, registrar esdeveniments de xarxa i un llarg etcètera.

Característiques i tipus de servidors intermediaris

Els servidors intermediaris es caracteritzen per interceptar les connexions de xarxa que un client emet cap a un servidor de destinació.

El servidor intermediari més conegut és el servidor intermediari de web. Aquest equip té com a missió interceptar totes les peticions dels clients que sol·liciten pàgines web. Per què s’utilitza un servidor intermediari per consultar un web? En principi, això sembla que no tingui sentit, ja que l’accés es ralentitza, però el servidor intermediari web ofereix seguretat i rendiment, i permet ocultar identificacions, entre altres coses.

A part del servidors intermediaris web existeixen els servidors intermediaris ARP, els servidors intermediaris FTP i els servidors de patró de disseny (presents en entorns de programació).

Els servidors intermediaris es poden classificar depenent de qui desitgi implementar la política a aplicar: servidors intermediaris locals o servidors intermediaris externs.

En un servidor intermediari local implementa la política el mateix equip que realitza la petició.

Parlar d’un servidor intermediari local vol dir que el mateix client pugui establir regles de filtratge, control de trànsit o gestió d’accessos des de la màquina amb què treballa i realitza peticions de serveis.

En un servidor intermediari extern implementa la política un equip diferent al que realitza la petició.

Habitualment, els servidors intermediaris externs s’utilitzen per gestionar memòries cau, trànsit de xarxa o compartició de serveis i recursos. Els avantatges més destacats que ofereix la utilització de servidors intermediaris externs són la possibilitat de limitar l’accés als usuaris, forçant-los a passar pel servidor, restringir drets d’usuaris, estalviar recursos, millorar la velocitat de resposta dels serveis, filtrar el trànsit prohibit o modificar informació segons les necessitats. Però també presenta una sèrie d’inconvenients, ja que pot tenir un excés de càrrega que ralentitzi les connexions, pot generar situacions d’intromissió o es pot lliurar informació no actualitzada.

Funcions principals dels servidors intermediaris

Són diverses les funcions dels servidors intermediaris. La gestió de peticions, la gestió de la velocitat de resposta, el filtratge de continguts, l’emmascarament d’identitat o la gestió de continguts a demanda són possiblement els casos més utilitzats.

Gestió de peticions

Gestionar les peticions a un determinat servei o recurs és sens dubte una de les funcionalitats estrella dels servidors intermediaris. Aquesta acció permet reduir dràsticament el trànsit que es genera en una xarxa quan els recursos o serveis són limitats i s’han de compartir.

Optimitzar els recursos

En determinades ocasions un lloc web és consultat per molts equips en una franja de temps petita. Si no se’n fa la gestió oportuna, això pot provocar la pèrdua de l’accés a Internet. Imagineu un nombre elevat d’equips sol·licitant consultar el mateix web: arribarà un moment en què l’accés a Internet no podrà oferir una qualitat de servei correcta. Solució: instal·lar un servidor intermediari que mantingui en la memòria les parts més sol·licitades del web que s’està consultant. Ara els equips de xarxa consultaran el web a la velocitat de la xarxa interna sense haver de sortir a Internet i provocar el col·lapse de la línia d’accés a l’exterior.

Com es pot observar en la figura, l’equip del client demana al servidor intermediari que demani l’hora a una altra màquina. La màquina que informa de l’hora es comunica amb el servidor intermediari, el qual envia les dades a l’equip client.

Figura Servidor intermediari gestor de peticions

Com que la memòria dels servidors intermediaris que gestionen peticions no és infinita, requereixen l’ús d’algorismes que s’encarreguen d’anar renovant les entrades.

Quan fa temps que un lloc web no és sol·licitat s’allibera la memòria que s’utilitzava per emmagatzemar les seves dades, i així queda disponible per a noves consultes.

Gestió de la velocitat de resposta

Aprofitar la xarxa local

Amb periodicitat semestral apareixen distribucions millorades del sistema operatiu Ubuntu. Per actualitzar les màquines no es permet que accedeixin totes a Internet, sinó que l’actualització es baixa a una màquina local de la xarxa i la resta d’equips hi accedeixen a la velocitat de la xarxa interna. La gestió de la velocitat de resposta és sens dubte un dels punts forts dels servidors intermediaris.

És habitual estar constantment enviant i rebent dades d’Internet, però potser no té gaire sentit anar moltes vegades a buscar una mateixa informació a l’exterior. Una manera eficient de treballar és descarregar els continguts d’Internet una vegada i distribuir-los a la velocitat de la xarxa interna. La velocitat és un dels factors que surt guanyant en aquest cas.

Filtratge

Els servidors intermediaris permeten realitzar el filtratge de continguts, com per exemple determinats tipus de fitxers. És força comú que les xarxes corporatives no permetin el trànsit de correu que contingui fitxers adjunts o que determinats perfils d’usuari no accedeixin a continguts externs a la intranet.

Un mètode per tal d’evitar introduir virus a la xarxa d’una empresa és no permetre l’entrada de correus que continguin fitxers adjunts.

Emmascarar la identitat

En ocasions pot resultar útil amagar a un servidor la identitat d’una màquina que sol·licita un servei. El servidor que ofereix un recurs o un servei detecta que un servidor intermediari està realitzant una petició i no reconeix quina és la màquina que realment fa la sol·licitud.

Continguts a demanda

Determinats servidors intermediaris s’utilitzen per modificar la presentació de la informació. Depenent del dispositiu (tauleta, PDA, telèfon intel·ligent, PC…) o del navegador utilitzat hi ha continguts que requereixen una modificació per poder ser visualitzats correctament.

La importància de la imatge

Si es consulta el web de segons quins diaris des de diferents plataformes es pot comprovar que el format de la pàgina s’adapta per oferir la màxima llegibilitat en cadascuna d’elles.

Configuració i utilització de servidors intermediaris

Parlar de servidor intermediari en general no té gaire sentit. Els servidors intermediaris són dispositius o programes que realitzen unes funcions determinades segons els seus objectius, que poden ser molts i variats. Això fa que la seva configuració i utilització variïn.

Tipus de servidors intermediaris

Actualment el mercat ofereix tot de servidors intermediaris específics per complir determinades funcionalitats. La identificació d’aquestes funcions permet crear etiquetes com ara servidor intermediari de web, servidor intermediari proxy, servidor intermediari transparent, servidor intermediari SOCKS, servidor intermediari invers, servidor intermediari obert i servidor intermediari d’emmascarament.

Servidor intermediari de web

A vegades es necessita disposar d’un mecanisme per concentrar l’accés a una intranet o a Internet des d’una xarxa informàtica i, alhora, quan el trànsit és elevat i hi ha moltes peticions a continguts cal evitar la baixada de la velocitat d’accés.

Els servidors intermediaris de web possibiliten l’accés al web i ofereixen memòria cau per millorar la velocitat d’accés a continguts.

El funcionament d’aquest servidors és molt senzill i alhora molt productiu. Quan un usuari vol realitzar una consulta al web, primer passa pel servidor intermediari. Si la informació que busca s’ha consultat amb anterioritat, en comptes d’anar a la web original, el servidor web intermediari mostra els continguts emmagatzemats en la seva memòria. En resum, no cal sortir al web per accedir a uns continguts que un altre usuari ha consultat recentment. La velocitat de resposta del servidor intermediari web és molt més alta que la que possibilita el servidor públic.

L’ús de servidors intermediaris web, però, presenta un inconvenient: pot passar que una informació emmagatzemada en la memòria del servidor intermediari canviï en el servidor web original, la qual cosa farà que les dades que lliuri el servidor intermediari no es corresponguin amb la informació real que es vol consultar.

Servidor intermediari proxy

Les xarxes en les quals conviuen molts equips o en les quals cal filtrar tots els requeriments a un servei requereixen la utilització d’un servidor intermediari proxy per millorar l’eficàcia de funcionament de la xarxa.

Un servidor intermediari proxy s’interposa entre els usuaris i l’accés a un servei. Generalment es facilita l’accés al servei mitjançant una aplicació web.

No s’ha de confondre un servidor intermediari proxy amb un servidor intermediari web, ja que el segon ofereix l’accés a un recurs determinat: el web. En canvi, el servidor intermediari proxy està obert a qualsevol tipus de recurs o servei.

Servidor intermediari transparent

Quan es parla d’utilitzar recursos transparents ens referim a fer ús d’equips sense que l’usuari hagi de realitzar cap modificació en la seva configuració. Utilitzar equips no transparents implica que en un moment o un altre, l’usuari, que tindrà més o menys coneixements, haurà de realitzar algun tipus d’acció en el seu equip. Això genera dos grans problemes: el primer és que un usuari inexpert no pugui accedir al recurs o serveis, i el segon, que els usuaris experts i no autoritzats obtinguin informació sobre la configuració i detecten vulnerabilitats.

Un servidor intermediari transparent ofereix accés a recursos i serveis sense que l’usuari hagi de fer cap canvi de configuració.

Un exemple de l’ús de servidors intermediaris transparents és el que fan les empreses proveïdores d’Internet: quan contracten un servei d’accés a Internet l’únic que cal fer és connectar l’equip d’accés, generalment un encaminador preconfigurat, i deixar tots les opcions de l’equip en automàtic.

Servidor intermediari SOCKS

En ocasions el nivell de seguretat de les comunicacions entre ordinadors ha de ser molt alt. Per aconseguir-ho, una opció és permetre l’accés a un servidor extern únicament a un equip determinat.

Un servidor intermediari SOCKS és l’únic equip que té accés a un servidor extern. Qualsevol usuari que desitgi accedir a aquest servidor extern ha d’establir prèviament connexió amb el servidor intermediari SOCKS.

L´ús de servidors intermediaris SOCKS està molt vinculat a aplicacions que ofereixen connexions segures, com per exemple PuTTY. El servidor intermediari SOCKS utilitza un protocol de la capa 5 que s’anomena SOCKS. Quan s’estableix la comunicació entre l’equip de l’usuari i el servidor intermediari SOCKS, el client demana tot el que li cal al servidor intermediari, que s’encarrega de fer les peticions a l’exterior.

Servidor intermediari invers

Si la raó de ser dels servidors intermediaris és estar al mig del camí de l’accés d’un equip intern a una xarxa externa, a vegades cal fer el mateix, però a la inversa.

Un servidor intermediari invers intercepta el trànsit de l’exterior que va cap a un servidor intern.

Interceptar el trànsit d’entrada a la xarxa n’augmenta la seguretat: el servidor intermediari invers ofereix una capa més a l’estratègia de seguretat implantada. Una altra raó per al seu ús, també lligada amb la seguretat, és que si es necessita xifrar la comunicació de l’exterior cap a un equip de l’interior de la xarxa, per exemple amb SSH, el servidor intermediari invers s’encarregarà de permetre la sessió SSH. Un servidor d’aquest tipus també podria repartir la càrrega cap a diferents equips interns, o fer de servidor cau per a la xarxa interna.

Servidor intermediari obert

L’usuari habitual de serveis com Internet coneix conceptes com llista negra. Estar en una llista negra implica que se’ns negui l’accés a diversos continguts o s’interceptin correus electrònics lligats a un determinat domini. Quan s’investiga per què s’ha afegit el nostre domini en una llista negra la resposta més comú és que enviem correu brossa o que els nostres equips s’utilitzen com a plataforma de salt. Si no és així, acostuma a ser degut a una gestió deficient d’un servidor intermediari obert.

Un servidor intermediari obert accepta les peticions d’equips que no tenen per què formar part de la seva xarxa.

Quan un equip que no forma part de la xarxa es connecta al servidor intermediari obert i fa qualsevol petició, a ulls externs la petició l’ha realitzat el servidor, per tant, sigui el que sigui el que estigui fent l’usuari, es vincularà al servidor intermediari obert i, en conseqüència, a l’administrador del servidor.

Servidor intermediari d'emmascarament

El funcionament habitual d’una xarxa informàtica és que els equips que en formen part de la xarxa local tinguin una adreça privada i accedeixin a l’exterior de la LAN amb una única IP pública. Això és possible gràcies a un pas previ: l’emmascarament.

Un servidor intermediari d’emmascarament s’encarrega de permetre als equips d’una xarxa interior l’accés a l’exterior utilitzant una adreça pública.

La utilització d’un servidor intermediari d’emmascarament afegeix seguretat a la xarxa, ja que els equips de la xarxa interna no queden exposats a atacs perpetrats des de l’exterior.

Exemples de servidors intermediaris

Al mercat es poden trobar diversos exemples molt interessants de servidors intermediaris. Cada vegada més la seva instal·lació està esdevenint una pràctica habitual a causa de la facilitat d’administració i la gran quantitat de possibilitats que ofereixen.

Servidors intermediaris com ara Squid, Ziproxy o Polipo són casos prou coneguts que cada vegada més són presents a les xarxes informàtiques.

Squid

Un dels servidors intermediaris més populars en entorns Unix és Squid. Aquest programari implementa un servidor intermediari i un domini per a memòria cau de llocs web.

  • Logotip del programa Squid/-12
  • Logotip del programa Squid

Squid disposa de la majoria de funcionalitats pròpies dels servidors intermediaris:

  • Permet l’accés web a màquines privades que no estan connectades directament a Internet.
  • Registra el trànsit web que surt de la xarxa local.
  • Controla l’accés web utilitzant regles.
  • Funciona com a memòria cau de pàgines web.
  • Controla el contingut web consultat.
  • Controla les descàrregues que es realitzen.
  • Implementa una memòria cau per a les connexions fallides.
  • Emmagatzema en la memòria cau les peticions DNS.
  • És compatible amb el protocol ICP.
  • Registra totes les peticions realitzades.

Squid s’ha d’instal·lar en una màquina que se situarà entre les màquines dels usuaris i una altra xarxa (per exemple Internet). Squid farà de frontera entre xarxes, separant-les i permetent accelerar l’accés a llocs web o restringint l’accés a continguts.

Squid permet centralitzar el trànsit de la xarxa local cap a una altra xarxa.

Només la màquina que té instal·lat Squid ha de disposar d’accés a la xarxa d’Internet.

Un detall molt important a tenir en compte és que la màquina que tingui instal·lat Squid ha de tenir dues interfícies de xarxa per tal de poder exercir de frontera. Una interfície s’utilitza per tenir accés a la xarxa local i l’altra per proporcionar accés a Internet.

No hem de confondre Squid amb un servidor web. Squid emmagatzema les dades que sol·liciten els clients i així les pot oferir a altres peticions a gran velocitat, però no ofereix pàgines web per sí mateix. Squid només permet accedir a les pàgines originals si detecta que s’hi han produït modificacions.

Existeixen programes que ajuden a configurar i a operar amb squid, com per exemple Gadmin-Squid.

Ziproxy

El servidor intermediari Ziproxy permet reduir la mida d’imatges JPG i comprimir fitxers HTML. Aquestes accions optimitzen la navegació i accés a dades. A més, aquest servidor intermediari optimitza la càrrega d’HTML, JavaScript i CSS.

No necessita programari client i dóna resultats en qualsevol navegador i sistema operatiu.

Polipo

Polipo és un servidor intermediari de memòria cau per a navegació. Es tracta d’un programa molt lleuger que no presenta cap complicació en la instal·lació ni en la configuració.

Polipo està als repositoris oficials d’Ubuntu i es configura mitjançant el fitxer /etc/polipo/config. El canvi de configuració no s’aplicarà fins que no es reinicii el programa.

Instal·lació de servidors intermediaris

La instal·lació física dels servidors intermediaris és bàsica per aconseguir la màxima eficiència de la xarxa.

Un servidor intermediari s’ha de situar entre la màquina de l’usuari i la xarxa externa, generalment Internet.

Només d’aquesta manera es pot centralitzar el trànsit de la xarxa local cap a l’exterior. Totes les peticions cap a l’exterior dels equips de la xarxa local hauran de passar per el servidor intermediari.

Instal·lació d'Squid

La instal·lació d’Squid es pot fer des dels repositoris oficials d’Ubuntu amb la línia:

sudo apt-get install squid

Els directoris amb els quals s’ha de treballar són:

  • /usr/bin/: directori executable
  • /var/run/: directori amb el PID del procés
  • /var/log/squid/: directori de registres
  • /var/spool/squid/: directori de memòria cau
  • /etc/squid/: fitxers de configuració
  • /usr/lib/squid/: complements
  • /usr/share/doc/squid/: documentació

Després d’instal·lar Squid caldrà canviar-ne la configuració per poder treure-li rendiment. El fitxer de configuració d’Squid és squid.conf. Els paràmetres més importants a considerar són:

  • http_port: indica el port que s’utilitzarà per escoltar el servidor. Per defecte aquest valor és 3128.
  • cache_mem: defineix la memòria RAM que s’utilitzarà per emmagatzemar les dades que més se sol·licitin.
  • cache_swap_low: indica el nivell d’espai mínim que s’ha de mantenir en l’àrea d’intercanvi.
  • cache_swap_high: indica el nivell d’espai màxim que s’ha de mantenir en l’àrea d’intercanvi.
  • maximum_object_size: indica la mida màxima que poden tenir els objectes que s’emmagatzemen en la memòria cau.
  • hierarchy_stoplist: indica els caràcters que s’utilitzaran com a filtre. Si els caràcters es detecten en una adreça web es carrega directament el contingut des de la memòria cau.
  • visible_hostname: indica el nom de l’equip.
  • cache_dir: estableix la mida que es reservarà en el disc per a la memòria cau.
  • access_log: indica el directori en què s’emmagatzemaran els accessos a Squid.
  • cache_log: estableix la ruta en què s’emmagatzemaran els missatges de log d’Squid.

Configuració de filtres

Els filtres que es configuren en els servidors intermediaris utilitzen majoritàriament llistes de control d’accés, conegudes com a ACL.

Les llistes ACL realitzen una acció sobre els paquets que tinguin determinades característiques. Una ACL s’ha d’identificar amb un nom o un número i cada regla especifica una condició i una acció. Les accions que es poden executar són permetre o denegar tots els paquets que acompleixin una condició.

acl nom_o_numero acció condició

Si un paquet compleix la condició se li aplicarà l’acció. Les accions són només permetre o negar, i les condicions depenen del tipus d’ACL. Les ACL més senzilles, anomenades estàndard, especifiquen valors per comparar amb l’adreça IP d’origen del paquet, mentre que en les ACL anomenades extenses les condicions permeten especificar valors per comparar IP d’origen, IP de destinació, protocols de capa 4, ports, indicadors de TCP…

Configuració de filtres amb Squid

Hi ha disponibles diversos elements per treballar amb ACL. És imprescindible fer una petita descripció de cadascun d’ells per tal d’aplicar les regles amb la lògica amb la qual han estat dissenyades:

  • src: especifica una o diverses adreces de xarxa o un segment de la xarxa amb la seva màscara corresponent.
    Una regla anomenada “xarxa_servidors” que té assignada la subxarxa 192.168.10.0/24 seria:
     acl xarxa_servidors src 192.168.10.0/24


    Per indicar un conjunt d’adreces de xarxa s’utilitzaria també l’ordre src:

    acl equips_publics src 192.168.10.5 192.168.10.7 192.168.10.27


    I fins i tot es poden indicar les adreces des d’un fitxer:

    acl produccio src “/etc/squid/p_produccio”


    Per a una sola adreça IP:

    acl administrador src 192.168.1.10/255.255.255.255


    O bé:

    acl administrador src 192.168.1.10/32


    Per definir una subxarxa:

    acl xarxa_inf src 192.168.1.0/255.255.255.0


    Per definir una llista d’adreces:

    acl programadors src 192.168.1.11 192.168.1.12 192.168.1.13


    La llista d’adreces de xarxa pot estar escrita en un fitxer i ser carregada:

    acl programadors src “/etc/squid/programadors.acl”


    Per crear una llista basada en un rang d’adreçes IP:

    acl programadors src 192.168.1.11-192.168.1.13


    “tothom”: s’utilitza per filtrar tots els equips d’una xarxa.

    acl tothom src 0.0.0.0/0.0.0.0


    La mateixa màquina d’origen: la nostra màquina serà l’origen de les connexions.

    acl localhost src 127.0.0.1/255.255.255.255

El tipus MIME d’un fitxer és una descripció del fitxer. Generalment s’utilitzen a la banda dels servidors perquè el gestor esculli la millor manera de mostrar l’element.

  • A més de treballar amb adreces IP es poden crear regles d’accés basades en ports, dominis, adreces web i tipus MIME:
    acl ports_segurs port 8080 23 443 1025-65535
  • dts: s’utilitza per indicar l’adreça de destinació en format IP i màscara o el nom de la destinació. Per exemple es podria declarar una regla que fes referència a adreces de xarxa de la nostra subxarxa:
    acl ips_departament dst 192.168.3.5 192.168.3.6 192.168.3.7
    O fins i tot de servidors de correu habituals:
    acl correus dst www.gmail.com www.hotmail.com www.webmail.com


    La mateixa màquina com a destinació.

    acl localhost_destinacio dst 127.0.0.0/255.255.255.255
  • srcdomain: serveix per donar accés a dominis determinats. Aquesta regla no funcionarà si no es disposa d’un DNS local. El cas següent indicaria els noms d’equip que pertanyen a la xarxa:
    acl equips srcdomain servidorweb.lamevaxarxa.com servidorcorreu.lamevaxarxa.com repositori.lamevaxarxa.com
  • dstdomain: estableix els permisos sobre els dominis web de destinació. Per exemple, es podria utilitzar per etiquetar els dominis prohibits:
    acl dominis_prohibits dstdomain .messenger.com live.com jocs.com
  • srcdom_regex: és la responsable d’avaluar text d’entrada a la xarxa. Si, per exemple, volem analitzar les paraules “examen” que circulin per la nostra xarxa farem:
    acl xarxa_local srcdom_regex -i examen\..*
  • dstdom_regex: s’encarrega d’avaluar text de sortida de la xarxa. Si per exemple volem analitzar totes les paraules de sortida que continguin “google” s’aplicarà:
    acl consulta_google dstdom_regex -i google\..*
  • time: marca el temps límit de connexió dins d’una setmana. S’utilitza un paràmetre per indicar cada dia de la setmana segons la taula. I les hores s’utilitzen seguint el format de vint-i-quatre hores. Si, per exemple, es vol habilitar una regla per als dissabtes i diumenges de vuit del vespre a onze de la nit:
    acl caps_setmana_nit time AS 20:00-23:00
Taula Paràmetre que indica el dia de la setmana amb Squid
Dia de la setmana Paràmetre
Dilluns M
Dimarts T
Dimecres W
Dijous H
Divendres F
Dissabte A
Diumenge S
  • url_regex: permet especificar text que aparegui en adreces web i interceptar la informació. El més habitual és emmagatzemar en un fitxer les paraules a les quals volem aplicar el filtre:
    acl webs_prohibits url_regex “/etc/squid/webs/prohibits.txt”
  • urlpath_regex: s’utilitza per poder administrar el trànsit de dades utilitzant l’extensió dels fitxers. És habitual utilitzar un fitxer per emmagatzemar les extensions a considerar:
    acl pelis urlpath_regex “etc/squid/filtres/peelis.txt”
  • req_mime: amb aquest tipus de regla es comprova el tipus de petició MIME realitzada per un client. Per filtrar trànsit del programa Messenger de Microsoft:
    acl messenger req_mime type application/x-msn-messenger
  • macaddress: permet realitzar l’administració utilitzant les adreces MAC dels equips. Per exemple, per controlar els equips de direcció utilitzant les seves adreces MAC:
    acl mac_direccio arp 1C:75:08:AC:**:** 1C:75:08:AD:**:** 1C:75:08:AD:**:**
  • password: pot controlar l’accés a Internet utilitzant un nom d’usuari i una contrasenya.

Utilització d'usuari i contrasenya per accedir a un servei

L’exemple següent mostra pas a pas el procediment a seguir per establir autenticació per accedir a un servei:

  1. Crear un fitxer que contingui les claus d’accés:
    vi claus
  2. Donar permís d’escriptura i lectura:
    chmod 600 claus
  3. Canviar el propietari:
    chown squid.squid claus
  4. Crear l’usuari i la contrasenya per accedir a Internet:
    htpasswd claus clients
  5. Modificar el paràmetre “auth_param”:
    auth_param basic program
    /usr/lib/squid/ncsa_auth /etc/squid/claus
  6. Habilitar la regla:
    acl password proxy_auth REQUIRED
  • http_access: el control d’accés es realitza amb http_access. Per permetre l’accés als equips vinculats a la regla “estudiants” escriurem:
    http_access allow estudiants


    I per no permetre l’accés als equips vinculats a la regla “visitants” afegirem:

    http_access deny visitants


    Permetre o negar l’accés a una o més ACL: amb el paràmetre allow es permet l’ACL i amb deny es denega. En l’exemple següent se’ns permet l’accés encara que no siguem programadors:

    http_access allow ! Programadors

El símbol ! indica que l’ACL no es verifica.

Configuració de l'emmagatzematge en memòria cau d'un servidor intermediari

Un dels problemes més habituals dels servidors intermediaris és la gestió de l’emmagatzematge en memòria cau. En alguns servidors, com per exemple Polipo, gestionar deficientment la memòria pot provocar deixar sense memòria la màquina que allotja el servidor. Aquest problema es reprodueix en la resta de servidors i Squid no n’és l’excepció. Utilitzarem Squid com a exemple de dos processos: esborrar la memòria cau i evitar el servidor intermediari per realitzar determinades consultes.

Esborrar la memòria cau d'Squid

Una de les tasques que s’han de realitzar dins els procediments de manteniment d’un servidor intermediari Squid és netejar la seva memòria cau. Tot i que es tracta d’una acció molt senzilla i que a priori pugui semblar una tasca secundària, no és aquest el cas. Una mala gestió de la memòria cau pot inhabilitar el servidor.

Abans de fer cap acció vinculada a la memòria cau cal parar el dimoni d’Squid:

sudo service squid stop

Per comprovar que efectivament Squid està aturat:

sudo service squid status 

Per eliminar el contingut emmagatzemat a la memòria cau d’Squid es pot utilitzar la línia:

sudo rm -rf /var/spool/squid/*

Sovint, la informació emmagatzemada a la memòria cau d’Squid pot aportar dades que ajuden a interpretar problemes de la xarxa. Una bona opció per no perdre aquesta informació és fer-ne una còpia abans d’eliminar-la:

sudo mkdir /var/spool/squid/copia/
sudo mv /var/spool/squid/ /var/spool/squid/copia/

I ara només cal reiniciar el dimoni:

sudo squid start

Exemple de com no utilitzar la memòria cau amb Squid

El servidor intermediari Squid és una bona solució per millorar l’accés a Internet, però en determinades ocasions pot ser un problema.

Error en la visualització de dades

Suposem que estem esperant la publicació de la nota d’un examen. Cada cinc minuts consultem el web on s’ha de publicar la nota i aquesta no apareix. Se’ns ocorre trucar a un amic i aquest ens comunica que les notes s’han publicat fa un parell d’hores. Amb neguit tornem a consultar la pàgina web i res de res. Hi haurà algun problema amb la meva nota? No! El que passa és que des de la xarxa on estic fent la consulta hi ha un servidor Squid que no m’està mostrant l’última versió del web. El que no paro de consultar és una pàgina descarregada en local que no reflecteix els canvis!

El servidor intermediari Squid permet indicar dominis que no s’emmagatzemaran en memòria cau:

sudo vi /etc/squid/dominis_no_cache

Aquests dominis s’inclouran en un fitxer de text:

ioc.xtec.cat
gmail.com
hotmail.com

Una solució molt enginyosa que ofereix Squid és que permet indicar equips que no utilitzin la memòria cau del servidor intermediari. Aquesta acció es realitza mitjançant l’adreça MAC dels equips:

acl equip_sense_cau arp 1C-75-08-AC-**-**

I aquesta línia s’afegeix al fitxer de configuració

/etc/squid/squid.conf

Perquè aquest procediment tingui efecte caldrà reiniciar el dimoni amb:

sudo squid restart

Exemple de fitxer squid.conf

A continuació es mostra part del contingut del fitxer squid.conf, en el qual s’utilitzen alguns dels conceptes bàsics d’aquest programa:

Una opció molt interessant és donar un nom propi a Squid perquè aquest sigui més reconeixedor a la xarxa:

visible_hostname servidor_intermediari

A continuació es defineixen les diferents xarxes a tractar amb ACL:

acl xarxa_local src 192.168.0.0/24

També es marca l’horari de treball:

acl jornada_laboral time M T W H F 8:30-22:00

Per decissió administrativa s’ha decidit restringir una màquina de la xarxa:

acl maquina_restringida src 192.168.0.15

Per fer efectiva la restricció en la màquina anterior:

http_access deny maquina_restringida

I per permetre l’accés a la xarxa local durant les hores de feina:

http_access allow xarxa_local jornada_laboral

A causa del mal ús que es fa de la xarxa es decideix que no es pugui accedir a determinats continguts. S’editarà el fitxer webs_prohibits amb:

#fitxer: /usr/local/etc/webs_prohibits
www.webprohibit1.com
www.webprohibit2.com
www.webprohibitN.com

També es pot indicar en un fitxer quins són els llocs web permesos, i titular-lo, perexemple, webs_permesos:

#fitxer: /usr/local/etc/webs_permesos
ioc.xtec.cat

I ara només caldrà especificar les corresponents ACL en el fitxer de configuració d’Squid:

acl WebsPermesos dstdomain “/usr/local/etc/webs_permesos”
acl WebsProhibits dstdomain “/usr/local/etc/webs_prohibits”

També es podria combinar amb http_access la xarxa local, l’horari d’oficina i els llocs web permesos:

http_access allow xarxa_local jornada_laboral WebsPermesos

Mètodes d'autenticació d'un servidor intermediari

En funció del servidor intermediari que s’utilitzi es disposarà d’un ventall més o menys gran de possibilitats per treballar amb modes d’autenticació. Per entendre els modes d’autenticació bàsics caldrà comprendre dos conceptes molt importants: el tipus de desafiament (type of challenge) i les credencials substitutes (surrogate credentials).

El tipus de desafiament indica el tipus de desafiament que es trobarà un client.

En el món de la informàtica el tipus de desafiament consisteix a plantejar una pregunta a l’usuari, que ha de respondre adequadament per poder continuar. Es tracta d’un protocol d’actuació molt utilitzat des de fa molt de temps.

El tipus de desafiament més simple és demanar confirmar una contrasenya.

Les credencials substitutes consisteixen a utilitzar unes determinades credencials fictícies en comptes d’utilitzar les reals.

Els modes d’autenticació més habituals són:

  • Auto: el mode d’autenticació auto o default se selecciona en funció del que el client sol·liciti. Depèn del tipus de connexió i la configuració d’autenticació dels equips.
  • Proxy-IP: el servidor intermediari utilitza un type of challenge de manera explícita i la IP de l’equip client com a credencials substitutes.
  • Origin: el servidor intermediari treballa com si es tractés d’un servidor de comunicacions en temps real. Quan s’autentica la connexió es pot utilitzar com a credencial substituta.
  • Origin-IP: el servidor intermediari treballa com si es tractés d’un servidor de comunicacions en temps real i, a més, pot generar i presentar al client desafiaments.
  • Origin-Cookie: el servidor intermediari actua com un Origin-IP, però és capaç de generar una galeta (cookie) com a credencial substituta. És més segur que Origin-IP. S’ha de destacar que aquesta configuració permet treballar en servidor invers. Cal tenir en compte que només HTTP i HTTPS admeten galetes.
  • Origin-cookie-redirect: en aquest cas es redirigeix el client cap a una adreça virtual on es realitzarà el procés d’autenticació. Les galetes s’utilitzaran com a credencials substitutes.
  • SGOS 3.0: fent ús de regles predefinides al sistema, permet establir comunicacions segures.
  • From-IP: realitza un cerca de les credencials d’usuari. Quan caduca una credencial, busca la correspondència amb l’usuari i fa una cerca de noves credencials.
  • From-Cookie: es realitza una recerca de credencials vinculades a un usuari. Les galetes es relacionen amb un servidor intermediari i l’usuari adquireix un perfil específic per a cada domini.
  • From-Cookie-Redirect: en aquest cas s’envia la sol·licitud de l’usuari a una adreça virtual. L’usuari haurà de superar un type of challenge quan les credencials expirin.
  • From-IP_Redirect: aquest mode treballa gairebé igual que el From-IP, excepte que en aquest cas l’usuari és enviat a una adreça virtual abans de ser presentat.

Instal·lació i configuració de clients de servidors intermediaris

La utilització de servidors intermediaris comporta un pas previ: configurar els equips dels usuaris perquè utilitzin el servidor intermediari. En determinats casos, si la màquina del client està configurada per adquirir configuracions automàticament, no caldrà fer-hi cap canvi, però en d’altres és necessari configurar els navegadors.

Els navegadors més utilitzats són Internet Explorer, Firefox i Chrome. Per tant, caldrà estudiar com es configuren manualment els servidors intermediaris en aquests programes.

Configurar el servidor intermediari amb Internet Explorer

Més de la meitat dels usuaris domèstics utilitzen Microsoft Internet Explorer per navegar per Internet. La configuració del servidor intermediari és habitual quan l’usuari s’ha de connectar a Internet utilitzant una xarxa corporativa, i es dóna el cas que en general Internet Explorer detecta automàticament la configuració del servidor intermediari.

Si Internet Explorer no detecta la configuració caldrà seguir els passos següents:

  1. Obrir el Microsoft Internet Explorer.
  2. Prémer Eines.
  3. Fer clic a Opcions d’Internet.
  4. Activar la fitxa Connexions.
  5. Anar a Configuració de LAN.
  6. Al quadre Adreça indicar l’adreça del servidor intermediari.
  7. Al quadre Port indicar el port escaient.
  8. Fer clic a Acceptar per guardar els canvis.

Figura Configuració del servidor intermediari a Internet Explorer de Microsoft Windows

La interfície de configuració que utilitza Internet Explorer de Microsoft Windows és molt intuïtiva, tal com mostra la figura. En moltes ocasions la caixa Detectar la configuració automàticament estarà marcada i no caldrà fer cap canvi en la configuració.

Configurar el servidor intermediari amb Firefox

Els passos a seguir per configurar el servidor intermediari en Firefox són els següents:

  1. Obrir el navegador Firefox.
  2. Fer clic a Edita.
  3. Prémer Preferències.
  4. Activar la pestanya Avançat.
  5. Activar la pestanya Xarxa.
  6. Fer clic a Paràmetres.
  7. Marcar Configuració manual del servidor intermediari.
  8. Indicar l’adreça i port del servidor intermediari.
  9. Si fos el cas, deixar marcat el quadre Utilitza aquest servidor intermediari per a aquesta xarxa.
  10. Fer clic al botó D’acord.
  11. Tancar el quadre de menús.

Figura Configuració del servidor intermediari a Firefox

Com es pot observar en la figura, en aquest cas els paràmetres de connexió permeten configurar una màquina com a servidor intermediari genèric i evitar que determinades consultes passin pel servidor intermediari.

Configurar el servidor intermediari amb Chrome

El navegador Google Chrome és el tercer en percentatge d’ús a nivell mundial. La configuració del servidor intermediari es realitza seguint els passos següents:

  1. Obrir el navegador Chrome.
  2. Fer clic a la clau que apareix a la cantonada superior dreta: Personalitza i controla Google Chrome.
  3. Prémer Configuració.
  4. Anar a la part baixa de la finestra i fer clic a Mostra la configuració avançada.
  5. Dins de Xarxa, ferclic a Canvia la configuració de proxy…
  6. Anar a Configuració de LAN.
  7. Indicar l’adreça del servidor intermediari i el port que utilitzi.

Figura Configuració del servidor intermediari a Chrome

En el cas de Google Chrome cal destacar que, tal com es mostra en la figura, el navegador utilitza en última instància les finestres d’interacció amb l’usuari del sistema operatiu instal·lat. La imatge ha estat capturada en un sistema operatiu Microsoft Windows.

Configurar servidor intermediari amb Safari

El navegador d’Apple també ofereix la possibilitat de configurar un servidor intermediari. Els passos a seguir són:

  1. Seleccioneu el menú Safari.
  2. Anar a Preferències.
  3. Activar la pestanya Avançat.
  4. A Proxies fer clic a Canviar preferències.
  5. A Configurar Proxies seleccionar Configurar manualment.
  6. Activar el quadre de protocol que es necessiti.
  7. Indicar l’adreça IP del servidor intermediari i el port que s’utilitzi.
  8. Prémer OK per guardar la configuració.

Figura Configuració del servidor intermediari a Safari

El navegador Safari ofereix la possibilitat, igual que Firefox, de configurar diversos servidors intermediaris relacionant-los a diferents protocols. En la figura s’assigna al servidor intermediari d’FTP un port diferent de l’usual.

Interpretació i utilització de documentació tècnica

Per considerar que un sistema està operatiu primer cal que passi pels entorns de proves, preproducció i producció. A més, cal generar documentació per poder fer el procés repetible, registrar els procediments associats al servei i establir un sistema de monitoratge perquè les fallades del servei siguin detectades.

Instal·lació i posada en marxa d'un sistema

Des del punt de vista de la seguretat, un sistema ha de passar per tres fases abans de posar-se en funcionament. Aquestes fases han de correspondre a l’estat de la instal·lació del sistema per evitar que una mala configuració d’un sistema de proves pugui ser la porta d’entrada d’un intrús.

Cal evitar que un entorn de proves estigui exposat a atacs externs per mitjà de la publicació de serveis.

  1. Entorn de proves. Primer de tot, cal disposar d’un entorn adequat per poder fer les primeres proves de funcionament del sistema. Convé que aquest entorn estigui el més aïllat possible, ja que en aquesta fase no es pot esperar que els serveis estiguin configurats correctament ni que els usuaris hagin de fer servir contrasenyes fortes.
  2. Entorn de preproducció. En una segona fase, el sistema ja està configurat com si estigués a punt de posar-se en producció. En aquesta fase, és possible que personal extern de l’organització hagi de poder accedir al sistema per fer-hi unes primeres proves abans de validar-lo i passar-lo a producció. Així, doncs, cal que el sistema tingui els serveis definitius, configurats correctament, publicats, però amb l’accés limitat. Un cop el sistema està validat, la documentació del sistema, els procediments per operar-hi i les degudes mesures de seguretat aplicades, es pot passar a l’entorn de producció.
  3. Entorn de producció. Un cop superades les fases anteriors, el sistema està llest per posar-se en funcionament. Això el farà més sensible a atacs, ja que tindrà menys restriccions d’accés. En aquest punt, s’hi ha de limitar l’accés i els registres s’han de controlar de manera periòdica per verificar-ne el funcionament sense incidències.

Un entorn de producció ha d’estar documentat i monitorat correctament. Igualment, ha de tenir les polítiques de seguretat adequades.

Documentació del sistema

Per tal d’instal·lar el sistema correctament, cal consultar la documentació del producte. Acostuma a estar en anglès.

L’anglès s’ha convertit en la llengua més utilitzada per a la documentació tècnica.

És habitual fer cerques amb cercadors per trobar configuracions predefinides. D’aquesta manera no s’ha de començar de zero. Tot i que la informació que es pot trobar a Internet pot ser molt útil, sempre cal comprovar-la i contrastar-la. És possible que les dades que es trobin continguin problemes de seguretat accidentals o intencionats. Si són intencionats, l’atacant espera que algú faci servir les dades i, després, aprofita la mala configuració del sistema per accedir-hi.

Durant el procés, cal documentar-ho tot, però especialment les fonts que utilitzem. Si emmagatzemem les dades en un sistema de gestió del coneixement, evitarem haver de repetir tot l’esforç que hem fet per posar el sistema en funcionament. D’aquesta manera, podrem repetir el procés seguint la documentació que hem generat prèviament.

MediaWiki és un programa de font pública que pot funcionar com a sistema gestor del coneixement.

Procediments del sistema

Un cop el sistema s’ha instal·lat correctament, també cal documentar com cal operar-lo per mantenir-lo en funcionament. A continuació, s’exposen uns quants procediments bàsics que permeten operar qualsevol sistema.

  1. Arrencada. Un dels procediments més importants és saber com cal arrencar un servei determinat. Alguns sistemes poden ser tan simples que només faci falta prémer el botó d’arrencada per fer-los funcionar. Tanmateix, en altres sistemes, el procediment pot ser més complex. Per exemple, per arrencar un clúster compost per un conjunt de balancejos de càrrega, un conjunt de servidors web i un conjunt de servidors de bases de dades, primer s’haurien d’arrencar les bases de dades, després els servidors web i finalment els balancejos. Si es fes a l’inrevés, les primeres capes saturarien les segones, que encara no estarien preparades, i l’arrencada podria fallar o trigar molt més temps.
  2. Comprovació del funcionament. Un cop arrencat el sistema, cal poder validar que funciona correctament. S’ha de comprovar que els components funcionen separadament i conjuntament. Per exemple, es pot comprovar separadament el funcionament d’un servidor web i el de la base de dades, però no es pot estar segur que funcionen en conjunt si no es fa una petició a la base de dades amb el servidor web.
  3. Comprovació de la configuració. En l’operació de qualsevol servei, el més normal és que s’hagin d’aplicar canvis en la configuració o que calgui afegir-hi entrades a mesura que passi el temps. Per això, cal saber com verificar la configuració abans d’aplicar-la.
    Aplicar una configuració sense cap verificació (error d’operació) sol ser una de les causes de caiguda dels serveis. Per això és important tenir ben documentats els passos que s’han de seguir per modificar-ne les configuracions i la manera adequada de verificar-hi els canvis.
  4. Aturada. L’aturada d’un servei, com l’arrencada, pot ser molt simple en la majoria dels casos, però, quan l’entorn és complex, pot ser més complicat. Seguim l’exemple del clúster: si primer s’apaga la base de dades i els servidors web continuen rebent peticions, aquestes peticions inacabables els poden saturar perquè no hi ha base de dades. Així doncs, en un entorn com aquest, el més adequat seria redirigir primer les peticions a un altre entorn en els balanceig de càrrega, apagar els servidors web i, finalment, les bases de dades.

Monitoratge del sistema

No es pot considerar que un sistema complex funciona correctament només pel bon funcionament, separadament, de les parts que l’integren, ja que el programari que fa interactuar aquests components també pot fallar.

És important que un sistema estigui monitorat constantment abans que passi a producció. D’aquesta manera, les fallades es detectaran quan es produeixin i es podran solucionar el més aviat possible.

És important monitorar els serveis per assegurar que es troben dins dels paràmetres del nivell de servei establert (també conegut com a SLA o Service Level Agreement).

Disponibilitat del sistema

La disponibilitat del sistema es compta com el percentatge del temps durant el qual el servei ha estat disponible. En cas de càlcul anual, per als percentatges de disponibilitat que es mostren a continuació, el temps d’aturada seria el següent:

  • 99%: 87 hores anuals (7 hores mensuals) d’aturada
  • 99,9%: 8 hores anuals (43 minuts mensuals) d’aturada
  • 99,99%: 52 minuts anuals (4 minuts mensuals) d’aturada
  • 99,999%: 5 minuts anuals (26 segons mensuals) d’aturada
  • 99,9999%: 30 segons anuals d’aturada

Supervisió i monitors reactius

Per millorar la disponibilitat del sistema, és habitual disposar d’un programa que supervisi els dimonis que hi pugui haver, ja sigui en un clúster o només en un node.

Daemontools és un programa de font pública que reinicia automàticament els dimonis quan s’aturen.

Aquest tipus de supervisió dels dimonis redueix considerablement el temps de caiguda dels serveis, ja que, en alguns casos, el problema se soluciona quan, simplement, el dimoni es torna a posar en funcionament.

Si el problema no és simplement un dimoni que té un error intern i s’atura, sinó que es tracta d’un procés que, tot i estar actiu, ha deixat de respondre, cal tenir un monitor configurat amb una acció definida que ha de dur a terme en cas que això passi.

Monit és un programa de font pública dedicat a la gestió de processos i sistemes de fitxers que permet fer tasques de manteniment de manera automàtica: permet configurar monitors reactius.

Realització d'informes d'incidències de seguretat

Quan hi ha un incident de seguretat, cal notificar l’incident als responsables dels sistemes involucrats i procedir amb cautela.

És bastant habitual entrar als equips involucrats i començar a remenar-los sense saber exactament què s’hi busca. D’aquesta manera, es poden destruir pistes que podrien ajudar a entendre què ha passat. Per tant, el primer que s’ha de fer és conservar la calma i seguir les recomanacions següents:

  • S’ha d’informar del possible incident de seguretat al responsable corresponent.
  • Cal esbrinar si es tracta realment d’un incident de seguretat. Moltes vegades, un mal funcionament d’un sistema pot ser degut a una sobrecàrrega legítima o a una mala programació.
  • Si realment és un incident, cal obtenir tota la informació possible per si pot servir de prova.
  • S’ha d’intentar contenir l’incident per evitar que es propagui, sempre s’han d’intentar reduir els danys. Pot ser que calgui bloquejar l’accés a l’equip o al conjunt d’equips involucrats.
  • Cal aplicar un pla per reduir o eliminar el risc que l’incident es torni a produir.
  • Finalment, cal documentar tant l’incident com el procés i la metodologia seguida.

L’informe sobre l’incident ha d’incloure els punts següents:

  1. Descripció
  2. Resum
  3. Anàlisi
Descripció

El document ha de començar amb una introducció sobre l’incident i un conjunt de dades bàsiques. Són les següents:

  • Breu descripció de l’incident a manera de títol.
  • Personal implicat.
  • Data i hora de l’inici de l’incident.
  • Data i hora en què es dóna per finalitzat l’incident.
  • Nivell d’afectació: es poden tenir diferents nivells amb diferents criteris, però això depèn de l’organització. De manera genèrica, es poden fer servir els nivells següents:
    • Greu: implica un problema de seguretat que ha causat danys en els sistemes afectats. Per tant, cal resoldre’l el més aviat possible i de manera ininterrompuda. Per exemple, si la base de dades principal de l’entitat queda fora de línia, caldrà una dedicació total per resoldre-ho.
    • Moderada: implica un problema que només ha degradat el servei o n’ha afectat parts no crítiques. Això sol indicar que la resolució s’ha de dur a terme durant la jornada laboral següent. Per exemple, si arran d’un atac de denegació de servei un sistema intern queda aturat, es pot resoldre quan la jornada laboral es reprengui.
    • Lleu: implica un problema que s’ha detectat, però no ha tingut cap impacte en els sistemes. Sol demanar un temps de resolució més llarg, per exemple, durant la setmana següent a la detecció. Quan apareix un error de programació en algun programa, cal aplicar els pedaços adients durant els dies següents.
Resum

A continuació de la descripció, cal fer un resum breu del problema, l’afectació, les causes i la solució perquè no es repeteixi. Mitjançant aquest resum, una persona sense coneixements d’informàtica hauria de ser capaç d’entendre què ha passat i quines mesures s’han pres per evitar que l’incident es repeteixi.

Anàlisi

L’anàlisi de l’incident ha de ser el cos del document i s’hi ha de poder seguir, pas a pas, què ha passat i com s’ha solucionat. Per això cal dividir aquesta anàlisi en tres parts diferenciades. Són les següents: procediment i metodologia, documentació i annexos.

1) Procediment i metodologia. És important definir com s’ha actuat envers l’incident per poder entendre, posteriorment, les decisions que s’han pres durant l’actuació. Tot i que el resultat pot ser el mateix, el mètode utilitzat pot invalidar les conclusions. Per exemple, si no s’ha comprovat la integritat d’un fitxer de registre, aquest fitxer pot haver estat alterat.

Un cop recollides les dades, cal poder verificar la validesa de totes les dades recollides.

Per poder estar segurs que les dades que mostra el sistema són reals, convé tenir les eines necessàries compilades estàticament (sense llibreries del sistema que hagin pogut ser manipulades). Aquests fitxers s’han de transmetre al sistema de manera que impedeixi que es puguin modificar, per exemple, mitjançant un CD-ROM.

Amb aquests fitxers d’anàlisi cal anar escrivint els resultats en un sistema remot que tingui un sistema de comprovació, per exemple, l’MD5 o el SHA1.

L’MD5 i el SHA1 són dos algorismes que generen un número de longitud fixa, que permet detectar si un fitxer ha estat modificat després de la seva creació.

Per conservar l’estat del sistema adequadament, és útil obtenir la informació següent:

  • Hora del sistema: permet identificar l’hora real dels registres. Si el sistema tingués una hora diferent de la real, els fitxers de registre també la tindrien modificada.
  • Taules amb informació volàtil: per exemple, pot ser interessant obtenir la taula ARP i la taula d’encaminament del sistema.
  • Connexions de xarxa: si l’atacant està connectat al sistema o envia ordres asincrònicament (sense mantenir una connexió activa) pot ser important tenir el conjunt de connexions actives i pendents.

La taula ARP conté les adreces físiques dels equips als quals el sistema està directament connectat.

A continuació, cal obtenir una còpia de totes les dades que puguin aportar alguna pista, com les dades i les metadades en disc. Convé obtenir aquesta informació mitjançant una imatge completa del disc.

Seguidament, es poden investigar els processos del sistema. Així, primer de tot cal esbrinar els mòduls que té carregats per si n’hi ha algun que pugui interferir en l’anàlisi. A continuació, pot ser útil verificar els processos actius, quins fitxers tenen oberts i quines crides al sistema estan fent.

El sistema de fitxers proc de Linux pot ajudar a fer una anàlisi dels processos actius.

Mitjançant totes aquestes dades, es pot obtenir una imatge bastant clara de l’estat d’un sistema.

2) Documentació. Durant la resolució d’un incident, el més normal és consultar documentació sobre el tema en qüestió, ja que és impossible tenir totes les dades al cap per poder actuar. Convé, doncs, apuntar tota la documentació, tant interna com externa.

En cas que sigui documentació interna, és especialment recomanable identificar quina s’ha fet servir per, després, poder-la corregir o adequar si és necessari.

Contràriament, si s’ha fet servir documentació externa, posteriorment es podrà contrastar la informació per veure si s’ha procedit adequadament i generar, després, documentació interna per poder actuar més ràpidament i no haver de dependre de tercers.

Existeixen una sèrie d’ítems que han d’estar sempre presents a la base de dades d’incidències:

  • Incidències detectades. Finalment, cal destacar la incidència o conjunt d’incidències detectades. Quan s’investiga un incident determinat, no és estrany detectar altres punts d’accés al sistema.
  • Pla d’acció. Un cop s’ha entès el problema, convé prendre mesures per evitar que es repeteixi en el futur. En determinar un pla d’acció, és possible trobar diverses situacions. A continuació, se n’exposen unes quantes.
  • Una mala configuració. Si el problema ha estat una configuració deficient, cal verificar tota la configuració del servei implicat, ja que s’hi podrien detectar altres problemes de configuració.
  • Un error sense pedaç disponible. Si el problema detectat és un error (bug) en la programació del servei que necessita un pedaç que encara no ha estat disponible, convindrà considerar diverses opcions.

Si és possible desactivar el servei fins que se solucioni el problema, es pot deixar desactivat per evitar futures intrusions mentre els desenvolupadors corregeixen el problema. En cas contrari, si el servei no es pot desactivar, caldrà veure si és possible mitigar el risc mitjançant alguna tècnica.

Generalment, s’utilitza una gàbia mitjançant el chroot per evitar que una fallada en un servei afecti tot el sistema.

El chroot permet aïllar un servei de la resta del sistema.

  • Un error amb un pedaç disponible. És possible que un cop investigat un incident, es detecti que cal aplicar un pedaç al sistema per corregir la porta d’entrada que s’ha fet servir per atacar-lo.

En aquest cas, cal deixar especificat el pedaç que s’hi ha d’aplicar per comprovar-lo en un entorn de proves abans d’aplicar-lo al sistema de producció.

  • Un mal ús dels serveis de xarxa. També és possible que es tracti d’un mal ús dels serveis publicats. Per tant, en aquest cas convindrà veure si és possible establir una política d’ús màxim del recurs per evitar que, en un futur, el mal ús del recurs per part d’un usuari provoqui la fallada del sistema per a tots els usuaris.

En alguns casos, és possible que el problema no sigui un mal ús de la xarxa ni un abús per part de l’usuari, sinó que el protocol mateix permeti comportaments no desitjats. Un exemple molt clar és el protocol SMTP i el problema del correu no desitjat. El lliurament d’un correu electrònic es basa en els dominis que té el servidor destinació i no hi ha manera de comprovar l’autenticitat de l’emissor. Per l’arquitectura del correu electrònic, un servidor qualsevol no es pot saber a priori si és un intermediari legítim o un servidor que envia correu no desitjat.

El problema se sol mitigar mitjançant llistes de servidors coneguts que envien correu no desitjat i un sistema de puntuacions heurístiques.

3) Annexos. Finalment, en els annexos es fan constar totes les dades que es creguin rellevants per entendre l’informe, com parts dels registres o ordres que s’han executat que puguin ser útils de cara a una anàlisi posterior.

Sol ser útil incloure-hi el registre complet de la sessió, perquè la resta de personal implicat en la resolució de la incidència el pugui veure.

Un guió (script en anglès) és una eina present en la majoria de distribucions Linux que permet enregistrar una sessió de consola.

Anar a la pàgina anterior:
Annexos
Anar a la pàgina següent:
Activitats