Diferència entre revisions de la pàgina «ASIX/M17/UF2/PT2»
m (Guillem ha mogut M17/UF2/PT2 a ASIX/M17/UF2/PT2 sense deixar una redirecció: Crear subnivell ASIX) |
|||
(Hi ha 41 revisions intermèdies del mateix usuari que no es mostren) | |||
Línia 1: | Línia 1: | ||
==Requeriments== | ==Requeriments== | ||
− | *Crear una MV amb CentOS o | + | *Crear una MV amb CentOS o qualsevol altre SO de servidor. Instal·lar un servei de DNS. |
− | *Crear una MV amb | + | *Crear una MV amb qualsevol SO. |
*MV amb Kali | *MV amb Kali | ||
Línia 15: | Línia 15: | ||
==Procediment== | ==Procediment== | ||
===DNS Amplification=== | ===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: <source> rate-limit {responses-per-second 3; window 15; };</source> | ||
+ | :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 <code>responses-per-second</code> é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 <code>window</code> 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: | ||
+ | <source> | ||
+ | hostnamectl set-hostname dns.guillem.test | ||
+ | </source> | ||
+ | |||
+ | Editarem l'arxiu <code>/etc/hosts</code> per tal de fer-hi constar el nom de host del propi servidor | ||
+ | <source> | ||
+ | 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 dns.guillem.test | ||
+ | ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 dns-guillem.test | ||
+ | </source> | ||
+ | |||
+ | Deshabilitarem el SELinux temporalment amb la comanda | ||
+ | <source> | ||
+ | setenforce 0 | ||
+ | </source> | ||
+ | :'''Nota:''' si ho volem fer permanent haurem de posar <code>disabled</code> a l'arxiu <code>/etc/selinux/config</code>. | ||
+ | |||
+ | Fet això podem començar amb la instal·lació del programari necessari per a posar en marxa el servei DNS pròpiament: | ||
+ | <source> | ||
+ | yum install bind bind-utils -y | ||
+ | </source> | ||
+ | |||
+ | 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 | ||
+ | <source> | ||
+ | [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: | ||
+ | </source> | ||
+ | |||
+ | L'arxiu de configuració principal és el <code>/etc/named.conf</code> 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à <source>listen-on port 53 { 127.0.0.1; 10.17.3.7; };</source> | ||
+ | |||
+ | *'''Línia 21: ''' canviarem ''localhost'' per ''any'' de manera que qualsevol màquina pugui fer consultes DNS al servidor <source>allow-query { any; };</source> | ||
+ | |||
+ | 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 <code>/etc/named.conf</code> | ||
+ | <source> | ||
+ | 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; }; | ||
+ | }; | ||
+ | </source> | ||
+ | |||
+ | 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 <code>/var/named</code>; pel que els dos arxius seran <code>/var/named/directa-guillem.test</code> i <code>/var/named/inversa-guillem.test</code> per a la zona directa i inversa, respectivament. | ||
+ | |||
+ | <source> | ||
+ | /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 | ||
+ | </source> | ||
+ | |||
+ | <source> | ||
+ | /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. | ||
+ | </source> | ||
+ | |||
+ | Finalment, amb la comanda <code>/usr/sbin/named-checkconf -z /etc/named.conf | ||
+ | </code> 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: | ||
+ | <source> | ||
+ | [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 | ||
+ | </source> | ||
+ | |||
+ | Ara ja podem arrencar i habilitar el servei DNS | ||
+ | <source> | ||
+ | systemctl enable named | ||
+ | systemctl start named | ||
+ | </source> | ||
+ | |||
+ | Podem fer consultes amb l'ordre <code>nslookup</code> per a comprovar-ne el funcionament | ||
+ | <source> | ||
+ | [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 | ||
+ | </source> | ||
+ | |||
+ | =====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. | ||
+ | <source> | ||
+ | yum install httpd -y | ||
+ | systemctl enable httpd | ||
+ | systemctl start http | ||
+ | </source> | ||
+ | |||
+ | Configurarem la targeta de xarxa per tal que tingui l'adreça <code>10.17.3.8/24</code> i utilitzi <code>10.17.3.7</code> com a DNS. Aleshores des del Kali (també configurada la NIC amb els paràmetres corresponents: IP <code>10.17.3.9 i DNS 10.17.3.7</code>), podem obrir el navegador web i accedir-hi normalment http://victim.guillem.test | ||
+ | {{imatge|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=== | ===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ó===== |
Revisió de 11:34, 15 abr 2020
Contingut
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; };
- 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:
- 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
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.