ASIX/M17/UF2/PT2

De Lordwektabyte Wiki
< ASIX/M17/UF2
La revisió el 11:34, 15 abr 2020 per Guillem (discussió | contribucions) (Guillem ha mogut M17/UF2/PT2 a ASIX/M17/UF2/PT2 sense deixar una redirecció: Crear subnivell ASIX)
(dif) ← Versió més antiga | Versió actual (dif) | Versió més nova → (dif)
Salta a la navegació Salta a la cerca

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

Necessitarem tenir instal·lat un servidor DNS. Optarem per instal·lar BIND en una màquina virtual CentOS 7 amb un adaptador de xarxa virtual en mode Xarxa NAT compartit amb el Kali Linux i un altre CentOS 7 amb un servidor web instal·lat que serà la victima. Primer de tot, definirem un nom de host identificatiu pel servidor DNS:

hostnamectl set-hostname dns.guillem.test

Editarem l'arxiu /etc/hosts per tal de fer-hi constar el nom de host del propi servidor

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 dns.guillem.test
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6 dns-guillem.test

Deshabilitarem el SELinux temporalment amb la comanda

setenforce 0
Nota: si ho volem fer permanent haurem de posar disabled a l'arxiu /etc/selinux/config.

Fet això podem començar amb la instal·lació del programari necessari per a posar en marxa el servei DNS pròpiament:

yum install bind bind-utils -y

Configurarem el Firewall del sistema per a permetre les connexions a través del port 53 tcp/udp, corresponent a l'estàndard pel servei de noms de domini

[root@dns ~]# firewall-cmd --add-port={53/tcp,54/udp} --permanent
success
[root@dns ~]# firewall-cmd --reload
success
[root@dns ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s3
  sources: 
  services: ssh dhcpv6-client
  ports: 53/tcp 54/udp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

L'arxiu de configuració principal és el /etc/named.conf que haurem d'editar per a poder permetre, entre altres coses, que el servidor respongui a queries DNS de les màquines de la xarxa:

  • Línia 13: afegirem l'adreça IP de la interfície virtual Xarxa NAT perquè la resta de VMs d'aquella xarxa puguin veure el servidor allà
    listen-on port 53 { 127.0.0.1; 10.17.3.7; };
  • Línia 21: canviarem localhost per any de manera que qualsevol màquina pugui fer consultes DNS al servidor
    allow-query     { any; };

Llavors haurem de declarar la zona DNS. Farem servir arxius separats per a la zona directa i la zona inversa. Afegirem el següent contingut al final de l'arxiu /etc/named.conf

zone "guillem.test" IN {
type master;
file "directa-guillem.test";
allow-update { none; };
};

zone "3.17.10.in-addr.arpa" IN {
type master;
file "inversa-guillem.test";
allow-update { none; };
};

Ara omplirem els arxius de la zona directa i inversa per tal que el DNS tingui registres. Al tractar-se de rutes relatives, es basa en el directori /var/named; pel que els dos arxius seran /var/named/directa-guillem.test i /var/named/inversa-guillem.test per a la zona directa i inversa, respectivament.

/var/named/directa-guillem.test
===============================

$TTL 86400
@ IN SOA dns.guillem.test. root.guillem.test. (

        2011071001 ;Serial
        3600 ;Refresh
        1800 ;Retry
        604800 ;Expire
        86400 ;Minimum TTL
        )

@ IN  NS dns.guillem.test.
@ IN A 10.17.3.7 
@ IN A 10.17.3.8 
@ IN A 10.17.3.9 

dns IN A 10.17.3.7    
victim IN A 10.17.3.8 
kali IN A 10.17.3.9
/var/named/inversa-guillem.test
===============================
$TTL 86400
@ IN SOA dns.guillem.test. root.guillem.test. (

        2011071001 ;Serial
        3600 ;Refresh
        1800 ;Retry
        604800 ;Expire
        86400 ;Minimum TTL
        )

@ IN  NS dns.guillem.test.
@ IN PTR guillem.test.

7 IN PTR dns.guillem.test.    
8 IN PTR victim.guillem.test.
9 IN PTR kali.guillem.test.

Finalment, amb la comanda /usr/sbin/named-checkconf -z /etc/named.conf podem verificar els arxius de configuració del BIND cercant possibles errors de sintaxi o similars. Si tot és correcte, ens donarà un output corresponent a les zones carregades:

[root@dns ~]# /usr/sbin/named-checkconf -z /etc/named.conf
zone localhost.localdomain/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 0.in-addr.arpa/IN: loaded serial 0
zone guillem.test/IN: loaded serial 2011071001
zone 3.17.10.in-addr.arpa/IN: loaded serial 2011071001

Ara ja podem arrencar i habilitar el servei DNS

systemctl enable named
systemctl start named

Podem fer consultes amb l'ordre nslookup per a comprovar-ne el funcionament

[root@dns ~]# nslookup dns.guillem.test
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   dns.guillem.test
Address: 10.17.3.7

[root@dns ~]# nslookup victim.guillem.test
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   victim.guillem.test
Address: 10.17.3.8

[root@dns ~]# nslookup kali.guillem.test
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   kali.guillem.test
Address: 10.17.3.9
Atac

Per a fer l'atac, instal·larem apache en un servidor CentOS i l'arrencarem. Per defecte hi haurà la pàgina per defecte d'Apache per a aquesta distribució de Linux.

yum install httpd -y
systemctl enable httpd
systemctl start http

Configurarem la targeta de xarxa per tal que tingui l'adreça 10.17.3.8/24 i utilitzi 10.17.3.7 com a DNS. Aleshores des del Kali (també configurada la NIC amb els paràmetres corresponents: IP 10.17.3.9 i DNS 10.17.3.7), podem obrir el navegador web i accedir-hi normalment http://victim.guillem.test

M17UF2PT2-1.png


Llavors farem servir Saddam des del Kali per a llançar l'atac DNS amplification a la màquina víctima:

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ó