Tallafocs

Hi ha molts mecanismes per gestionar la seguretat en les xarxes. Un d’aquests mecanismes consisteix a utilitzar els tallafocs, que permeten definir visibilitats entre els equips que componen la xarxa. D’altra banda, mitjançant programari específic es pot conèixer l’estat de la xarxa i els intents d’intrusió que s’hi poden produir. En cas que finalment s’arribi a produir la intrusió, caldrà tenir a punt un procediment d’acció per evitar mals majors com la destrucció de pistes o que es torni a produir el problema.

Utilització d'eines de control del monitoratge en xarxes

Per a un monitoratge i un control complets de la xarxa i els sistemes que integra, cal fer servir un conjunt d’eines diferents que permeti tenir-ne una visió segons les necessitats de cada moment: no és el mateix intentar veure el patró que ha seguit un atacant per intentar descobrir els serveis de xarxa que trobar un atac de denegació de servei en la xarxa.

1. Alertes del funcionament de la xarxa i els sistemes que integra.

Una primera eina imprescindible per controlar les xarxes és un sistema que avisa quan hi ha algun problema, sia per un mal funcionament del sistema o per un atac extern. Per tal que resulti una eina eficaç, cal configurar-la amb cura. D’aquesta manera, s’evitaran les notificacions errònies (falsos positius), la falta de notificació (falsos negatius) i les notificacions massives (la fallada d’un sistema fa saltar les notificacions de tota la resta).

En general, aquest sistema d’avisos hauria de permetre, almenys, els tres nivells següents:

• Correcte: el sistema opera dins els paràmetres normals.
• Avís: el sistema s’ha desviat dels paràmetres normals i això pot comportar un problema en el servei.
• Alerta: el sistema es troba degradat o inoperatiu.

Per evitar les notificacions massives hi ha dos escenaris possibles:

1. Si un element que deixa passar les comprovacions o les realitza per si mateix deixés de respondre, s’enviarien les notificacions no només de l’element que ha deixat de funcionar, sinó de tots els elements de què el servidor de monitoratge perd la visibilitat. Per evitar aquest cas, s’implementen dependències entres les comprovacions, de manera que abans d’enviar una notificació, cal verificar que l’element de què depèn funciona adequadament. Per tant, si falla un element determinat, només envia la notificació d’aquest element i no pas de tots els altres elements que en depenen.
2. Si un equip s’atura, tots els serveis que estiguin en aquest equip deixen de respondre. Per poder enviar una modificació que indiqui que el servidor està apagat i que no tots els serveis han deixat de respondre, normalment es defineix una comprovació que, si falla, notifica que tot l’equip està apagat i no envia les notificacions de tots els serveis que conté.

El Nagios és una eina de codi lliure que permet monitorar serveis.

2. Gràfics de l'estat de la xarxa i els sistemes al llarg del temps

Un atac acostuma a generar un trànsit inusual en la xarxa. Per tant, és important mantenir un registre per tal de comparar l’estat actual amb l’anterior. No té gaire sentit elaborar gràfics amb les dades binàries (estat correcte / estat alerta). Tanmateix, pot ser molt útil elaborar-ne un que mostri dades com el trànsit, les sessions concurrents o la càrrega del sistema.

Una eina de codi lliure molt utilitzada per fer gràfics, tant de trànsit com d’altres tipus de dades, és el Cacti.

3. Detall de l'estat de la xarxa a l'instant

En cas que hi hagi algun problema en la xarxa, pot resultar molt útil disposar d’una eina que permeti veure què hi passa en un moment determinat. És important disposar d’una eina que agrupi les dades i les mostri de manera que amb una ullada puguem veure com funciona la xarxa, quin tipus de dades hi ha, quin n’és l’origen i quina n’és la destinació.

Si les dades estan agrupades, és fàcil deduir si hi ha cap problema i, en cas que n’hi hagi algun, identificar-lo per mitigar-lo.

Ntop és una eina de codi lliure que fa aquesta anàlisi instantània de l’estat de la xarxa.

4. Gestió i anàlisi de registres

Els registres (logs) que deixen les aplicacions són la millor font d’informació a l’hora de detectar un atac i prendre mesures per evitar-lo. Per detectar la manipulació dels registres, es pot fer servir un sistema que s’encarregui de recollir totes les dades. A aquest sistema es pot afegir la data de recepció per poder correlacionar les dades, emmagatzemar-les i signar-les electrònicament per tal de detectar si s’alteren.

Hi ha moltes maneres de centralitzar els registres de les aplicacions, però en sistemes UNIX se sol utilitzar el dimoni Syslog.

Els passos que se segueixen per configurar un sistema d’emmagatzematge de registres amb Syslog són els següents:

1. Es configura un dimoni de Syslog a escala local perquè rebi els registres de les aplicacions i en conservi una còpia local durant un període de temps determinat. D’aquesta manera, es poden consultar directament des del sistema mateix.
2. Es configura un dimoni de Syslog en un sistema remot que accepti dades i les emmagatzemi ordenades per data.
3. El dimoni de Syslog del sistema en què hi ha l’aplicació va enviant una còpia dels registres al dimoni de Syslog remot.
4. Quan els registres es troben en el sistema remot, es fa una signatura electrònica per poder detectar si s’alteren.

Quan les dades ja estan emmagatzemades, s’hi poden aplicar eines que permetin agregar-les a un informe sobre l’estat del programari o el sistema. Per exemple, mitjançant l’aplicació LogWatch, les dades d’un sistema Linux es poden agrupar. D’aquesta manera, es pot enviar un informe sobre l’activitat a l’administrador de sistemes.

També hi ha programari de caràcter més específic, com l’AWStats, que permet analitzar els registres de servidors web. Amb aquest programa es poden extreure dades molt importants si l’atacant no ha pogut alterar el sistema d’emmagatzematge de registres.

L’AWStats és un programari d’anàlisi de registres d’activitat de servidors web, correu i FTP que mostra una llista d’errors 404 que ofereix molta información.

Activitat a investigar

En general, el que cal buscar en els registres són les anomalies, ja que és molt complicat fer encaixar l’activitat que es genera en fer un atac amb el funcionament normal del sistema. Quan busquem anomalies, també es detecten falsos positius, activitat legítima que sembla il·lícita. Així doncs, convé actuar amb cautela per no treure conclusions precipitades.

Per exemple, en el cas d’analitzar els registres d’un servidor web, es podria començar a analitzar l’activitat buscant els punts següents:

Els fitxers més consultats: entre els fitxers més populars és possible trobar contingut il·lícit si el servidor web s’està fent servir per distribuir-lo.

Evolució del trànsit: en cas que hi hagi un increment sobtat del trànsit de dades, seria factible que es tractés d’un intent de denegació de servei o bé que s’hi hagués introduït algun contingut fraudulent. Així doncs, per poder valorar què passa en el servidor web, caldria estimar l’evolució de bytes enviats, les consultes per unitat de temps i els totals de consultes per IP.

Consultes a fitxers que no existeixen (404): és possible que, per tal de comprometre un servidor web, s’hagi d’intentar diverses vegades. Algun d’aquests intents pot generar l’error 404 (not found), que queda registrat en els registres del servidor web. Si els errors 404 es comproven periòdicament, és possible tenir una idea del tipus d’atacs que pateix el servidor web en qüestió per prendre mesures.