Diferència entre revisions de la pàgina «ASIX/M17/UF2/PT2»

De Lordwektabyte Wiki
Salta a la navegació Salta a la cerca
Línia 23: Línia 23:
 
Una opció per a mitigar aquests atacs seria, en el cas de posseir un servidor DNS públic a Internet:
 
Una opció per a mitigar aquests atacs seria, en el cas de posseir un servidor DNS públic a Internet:
 
*Limitar l'ample de banda dedicat al servidor: de manera que no sigui "atractiu" pels atacants per a ser usat com a ''relay'' d'un atac destinat a una víctima. Les consultes i respostes DNS són paquets petits que no requereixen gaire ''bandwidth'', pel que es pot definir en un marge raonable perquè el DNS no respongui ràpid en cas d'atac destinat a una altra màquina.
 
*Limitar l'ample de banda dedicat al servidor: de manera que no sigui "atractiu" pels atacants per a ser usat com a ''relay'' d'un atac destinat a una víctima. Les consultes i respostes DNS són paquets petits que no requereixen gaire ''bandwidth'', pel que es pot definir en un marge raonable perquè el DNS no respongui ràpid en cas d'atac destinat a una altra màquina.
:*A part de l'ample de banda, també podem mitigar o fer menys atractiu el nostre servidor si li configurem ''rate limits'' de peticions com per exemple, en el cas de BIND:
+
**A part de l'ample de banda, també podem mitigar o fer menys atractiu el nostre servidor si li configurem ''rate limits'' de peticions com per exemple, en el cas de BIND:
 
<source>
 
<source>
 
rate-limit {
 
rate-limit {

Revisió del 15:49, 22 març 2019

Requeriments

  • Crear una MV amb CentOS o qualsevol altre SO de servidor. Instal·lar un servei de DNS.
  • Crear una MV amb qualsevol SO.
  • MV amb Kali

Enunciat

1. Descriu i mostra un possible atac de DNS Amplification
  • Com funciona? Mostrar un atac.
  • Com solucionar-lo. Mostrar la solució.
2. Descriu i mostra un possible atac de DNS Spoofing
  • Com funciona? Mostrar un atac.
  • Com solucionar-lo. Mostrar la solució.

Procediment

DNS Amplification

Teoria

Un atac de DNS amplification consta en atacar una víctima amb paquets de resposta DNS que no ha demanat; de manera que saturem la targeta de xarxa de la màquina víctima. A més a més, si aquestes respostes DNS estan "sobrecarregades" amb més dades com per exemple una consulta tipus all, o una petició de transferència de zona DNS, tindrem paquets més grans que arribaran a la víctima i que aquesta no podrà gestionar i podria arribar a quedar congelada o desconnectada de la xarxa.

Aquest atac pot fer-se de la mà d'un IP spoofing ja que des de la màquina atacant enviem peticions DNS a un servidor però posant l'adreça IP origen=adreça IP de la víctima. D'aquesta manera, el servidor enviarà la resposta a la que serà la vćitima. Si això ho combinem amb un sistema distribuït que faci vàries peticions des de diferents atacants cap a la mateixa víctima, podria utilitzar-se com a atac DDOS (Distributed Denial-Of-Service) fent que, tal com he dit abans, la víctima es saturi i pugui perdre la connectivitat de xarxa.

Mitigació

Una opció per a mitigar aquests atacs seria, en el cas de posseir un servidor DNS públic a Internet:

  • Limitar l'ample de banda dedicat al servidor: de manera que no sigui "atractiu" pels atacants per a ser usat com a relay d'un atac destinat a una víctima. Les consultes i respostes DNS són paquets petits que no requereixen gaire bandwidth, pel que es pot definir en un marge raonable perquè el DNS no respongui ràpid en cas d'atac destinat a una altra màquina.
    • A part de l'ample de banda, també podem mitigar o fer menys atractiu el nostre servidor si li configurem rate limits de peticions com per exemple, en el cas de BIND:
rate-limit {
    responses-per-second 3;
    window 15;
};
Amb aquests paràmetres farem que el servidor respongui, com a màxim, 3 peticions DNS per segon; de manera que ningú el pugui veure atractiu per a llançar un atac d'aquest tipus.
El responses-per-second és el màxim de consultes idèntiques que pot fer un client un segon. Els atacs de DNS amplification es basen en enviar respostes a consultes iguals per simplicitat i rapidesa; pel que aquest paràmetre pot ser interessant per evitar ser usats com a "base".
La finestra window especifica el temps en segons que un client DNS pot fer peticions DNS dins del límit definit pel responses-per-second. En l'exemple de sobre, doncs, un client podria fer un màxim de 3 peticions per segon cada 15 segons.
Aquests valors van lligats entre ells i han de ser coherents; ja que no tindria sentit permetre moltes connexions per segon en una finestra molt curta (burst) o bé posar una finestra molt gran perquè llavors un atacant que pogués deduir el rate màxim podria ajustar-se bastant per a usar-nos de base sense sortir de les normes.
  • No oferir recursivitat a adreces IP que no correponguin a la xarxa local: de manera que no faci consultes a altres servidors DNS si li arriba una petició d'un hostname que no està a la seva zona. Mentre que la xarxa local podrà fer-ho perquè és necessari.

En el cas de voler-nos protegir com a víctimes:

  • Podem utilitzar Firewalls d'alt nivell per a filtrar el trànsit DNS que no hagi estat demanat (ja que arriben respostes DNS a queries que no hem fet nosaltres).

Cas pràctic

Atac
Solució

DNS Spoofing

Teoria

L'atac de DNS Spoofing o DNS cache poisoning és un atac basat en corrompre els registres d'un servidor DNS deliberadament per a enviar dades incorrectes a les peticions DNS dels clients (potencials víctimes). En aquest atac, l'atacant es farà passar per un servidor DNS legítim per un domini; o bé corromprà els registres d'un servidor DNS legítim per tal de redirigir el trànsit a altres màquines, segurament sota el seu domini, per a aconseguir dades personals de la gent com ara noms d'usuari, contrasenyes, correus electrònics, etc.

Mitigació

L'única manera factible d'evitar aquests atacs és implementant DNSEC (DNS Secure); que seria un equivalent a HTTPS on es valida l'autenticitat de les dades rebudes a partir d'intercanvis de certificats que identifiquen el servidor DNS que envia les dades; evitant així que algú entremig pugui interceptar les dades i modificar-les on-the-fly ja que llavors la signatura hash variaria i el client no la donaria per bona.

Cas pràctic

Atac
Solució