oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: dns

Free dynamic DNS service

Reading time: < 1 minute A long time ago there were several free dynamic DNS services but nowadays it's difficult to find one of them. And when you find the service usually you have some important restrictions like: number of updates per day or only few subdomains per account. But in the end I found a good free service of that, it's part of the project guifi.net and is called: Qui; you only need a guifi.net account to use the service and it’s really simple and clear. From my part the compatibility with “ddclient” and the “mikrotik” script are really useful and I want tu highlight this functionality.

Zeroconf – quatre apunts que poden ser útils

Reading time: < 1 minute No tenia gaire frescos els mecanismes que usava Zeroconf per treballar, així doncs, arran d'un comentari fet pel Marcos he decidit invertir-hi una estoneta per fer-me uns petits apunts sobre el tema. Són quatre notes que he posat al wiki i que enllaço a continuació espero que ús siguin útils.

UDPTunnel – enviar els paquets UDP per sobre d’enllaços TCP

Reading time: < 1 minute Una altre d'aquelles eines que malgrat ser petitones i rares poden servir per fer mil i una coses. Per exemple, connectar a un servidor DNS a través d'un port TCP en una xarxa on el tràfic UDP estigui tancat. UDPTunnel és una eina molt simple d’usar i la seva sintaxis és molt autoexplicativa:

 udptunnel -s TCP-port [-r] [-v] UDP-addr/UDP-port[/ttl]
 udptunnel -c TCP-addr[/TCP-port] [-r] [-v] UDP-addr/UDP-port[/ttl]

és interessant fixar-se que el mateix executable pot ser usat com a servidor o com a client, així doncs ideal per construir els dos costats de l’enllaç de forma simple.
A més si ho combinem amb httptunnel podem passar per sobre de proxies de forma senzilla.

Atac DOS al DNS: DNS Root Query Amplification

Reading time: 2 – 4 minutes

El dia 26 un dels servidors que administro va ser víctima d’un atac DNS, de fet, a hores d’ara encara continuem sent víctimes de l’atac malgrat ara mateix ja hem pres mesures de contenció per tal de que el mateix no ens afecti. La qüestió és que aquest atac va sobrecarregar l’activitat del nostre servidor de DNS fins a tal punt que les peticions DNS trigaven molta estona a resoldres ja que s’acumulava la feina i aquestes cada cop trigaven més a resoldres. Això de forma col·lateral va provocar problemes en altres serveis, arribant fins hi tot a col·lapsar-los i a fer caure un dels servidors.

L’atac en qüestió esta perfectament descrit pel SANS:

Una possible solució i també descripció del problema la va trobar en Lluís en aquest blog:

Per resumir una mica el que es nota és que rebem moltíssimes peticions de resolució del domini ‘.’, cosa que dona molta feina al nostre servidor DNS i que acaba generant un gran tràfic de resposta per una petita petició que pot llençar perfectament un zombie sense patir cap sobrecarrega al seu ampla de banda, encanvi el destinatari del atac DOS pot veures afectat per moltíssims paquets no solicitats de diversos origens, convertint el simple atac DOS en un complicat atac DDOS difícil de parar pel destí final de l’atac.

Un bon gràfic per entendre l’atac és aquest:

dns-amplification-attack-small

Aquest gràfic l’he extret de l’article DNS Amplification Attack
del blog Security News & Tips. Que també té un bon article on s’explica l’atac en detall.

Si simplement sóm usats per llençar aquest atac, com era el cas que explico gràcies a eines com el fail2ban no és complicat d’aturar, ja que podem dir-li que vigili el nostre fitxer de logs i llençar regles de filtrat que aturin les peticions al DNS que es repeteixen massa pel mateix origen. Per un detall més complert de com implementar això ús remeto a l’article: DNS Root Query Amplification.

NOTA sobre PowerDNS: El software que usem per gestionar els DNS és el PowerDNS el qual disposa d’una interficie web per controlar les estadístiques del servei, en cas de patir un atac d’aquest tipus a través d’aquesta pàgina web serà molt senzill que identifiqueu quines IPs estan llençant l’atac i a més a més comprovar que l’atac és el del tipus que he descrit.

mini-remember: dig i DNS

Reading time: 1 – 2 minutes

Mai recordo aquest carai de paràmetre del dig:

oriol@mini2 ~ $ dig @80.35.31.228 joor.net axfr
; <<>> DiG 9.3.4 <<>> @80.35.31.228 joor.net axfr
; (1 server found)
;; global options:  printcmd
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
joor.net.               86400   IN      MX      20 s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      oriol.joor.net.
joor.net.               86400   IN      NS      s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      s1-ret.inforcomsoft.net.
joor.net.               86400   IN      A       83.175.213.75
adsl.joor.net.          86400   IN      A       62.37.147.231
bali.joor.net.          86400   IN      A       83.175.213.75
www.bali.joor.net.      86400   IN      A       83.175.213.75
dades.joor.net.         86400   IN      A       83.175.213.76
daphne.joor.net.        86400   IN      A       80.35.31.228
ftp.joor.net.           86400   IN      A       83.175.213.75
imatges.joor.net.       86400   IN      A       83.175.213.76
mail.joor.net.          86400   IN      A       83.175.213.75
medicinachina.joor.net. 86400   IN      A       80.35.35.228
oriol.joor.net.         86400   IN      MX      30 s0-ret.inforcomsoft.net.
oriol.joor.net.         86400   IN      A       80.35.31.228
s0.oriol.joor.net.      86400   IN      MX      30 s0-ret.inforcomsoft.net.
s0.oriol.joor.net.      86400   IN      A       80.35.31.228
tcm.joor.net.           86400   IN      A       80.35.31.228
webmail.joor.net.       86400   IN      A       83.175.213.75
www.joor.net.           86400   IN      A       83.175.213.75
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
;; Query time: 191 msec
;; SERVER: 80.35.31.228#53(80.35.31.228)
;; WHEN: Tue Apr 17 12:18:15 2007
;; XFR size: 23 records (messages 1)

Així que aquí queda el recordatori. Aprofito també per enllçar un petit manual que esta molt bé sobre el dig: Dig: consultando la configuración dns.

OpenDNS – els millors DNS que podeu usar per navegar

Reading time: 2 – 2 minutes

opendns.gif

Sovint quan et pregunten quins DNS li poso a la màquina acostumo a contestar 194.179.1.100 com a primari i 194.179.1.101 al secundari, això ho vaig aprendre a l’època del primer infovia el del 055. Des de llavors se m’han quedat grabats aquest parell de DNS públics. Doncs bé, si a més d’això a cada empresa que vaig, a la xarxa de la meva feina o la meva intranet a tot arreu hi tinc un servidor DNS intern llavors mai tinc la necessitat de configurar-me servidors DNS externs. Així doncs, mai havia tingut la necessitat de plantejar-me quins eren millor o pitjors i què m’oferien uns o altres. Doncs bé, aquest cap de setmana tot llegint el blog de l’Alex King, concretament l’article sobre l’OpenDNS he descobert aquest servei tan interessant.

Algunes de les avatatges de l’OpenDNS són:

  • Temps de resolució molt ràpid. Servidors per tot el món.
  • Correcció d’errors tipogràfics comuns (p.e. convertir .xom -> .com)
  • Avisa si s’intenta entrar en una pàgina de phishing. Per tant, és ideal per protegir d’aquests atacs.
  • Es pot forçar l’update d’un domini, forçant el refresc.
  • A més és gratuït. Viuen de la publicitat que posen a la web i a les pàgines de bloqueig de phishing.

DNS invers amb subnetting

Reading time: 5 – 8 minutes

dns.gif

A la feina tenim assignades 8 IPs públiques, o sigui que tenim una subxarxa (subnetting) de 8 IPs públiques cedides pel nostre ISP. El tema esta en que ens hem decidit a contractar l’auto-gestió de la resolució inversa de les IPs. En poques paraules que quan algú entri una IP del nostre rang aquesta es resolgui convenienment amb els nostres mnemonics i usant els nostres servidors. Perquè això passi els servidors DNS superiors (de la classe C) han de cedir el control del subrang d’IPs als servidors que nosaltres desitgem, en aquest cas, servidors de dintre el rang.

El problema esta en que després de que l’ISP fes els canvis pertients no ens va dir com haviem de preparar el nostre DNS per tal de fer això. Com que sempre que he fet això o ho he contractat i ja estava tot fet o bé era una xarxa de tipus C privada, mai havia tingut problemes de configuració ja que es fa igual que en tots els manuals, o sigui, trivial.

Doncs bé el problema va venir quan vaig veure que algo havia d’anar diferent i les ajudes que havia rebut no em donaben la solució així que vaig recorrer al Pof que tampoc se’n va sortir, així que espero explicar el tema prou bé com perquè almenys ell ho entengui. Abans de seguir amb el rotllo tècnic us sito les fonts d’on he tret la documentació per aconseguir que funcioni el tema:

  • DNS for Rocket Scientists fantàstica llista de recursos on hi ha tot tipus d’exemples de com montar un DNS, jo diria que amb el que hi ha aquí no et fa falta res més per saber dels DNS.
  • HOWTO Delegate Reverse Subnet Maps document extret de la llista anterior que com podeu deduir ens dona alguns exemples de com montar el que he comentat abans.
  • DNS Stuff un site, on es poden fer totes les proves que es pot arribar a necessitar per comprobar que un DNS públic funciona bé i algunes coses més.

Centrant-nos en el problema, resulta que si aplico literalment l’exemple del link que he citat abans (HOWTO Delegate Reverse Subnet Maps) no funcionava malgrat el servei de named no donava cap error i es llençava correctament. Raro,eh!? ni en local ni en remot no funcionava res de res. Doncs bé tota la gràcia del tema esta en com el DNS que ens esta fent el re-enviament de zona s’esta referint al nostre SOA, m’explico amb l’exemple del HOWTO esmentat.

Fitxer de la zona de tipus C (192.168.23.0/24):

$ORIGIN 23.168.192.IN-ADDR.ARPA.
@            IN  SOA   ns1.isp.com. root.isp.com. (
                              2003080800 ; serial number
                              2h         ; refresh
                              15m        ; update retry
                              2w         ; expiry
                              3h         ; minimum
                              )
              IN  NS      ns1.isp.com.
              IN  NS      ns2.isp.com.
; definition of other IP address 0 - 63
....
	; definition of our target 192.168.23.64/27 subnet
; name servers for subnet reverse map
64/27         IN  NS  ns1.mydomain.com.
64/27         IN  NS  ns2.mydomain.com.
; IPs addresses in the subnet - all need to be defined
; except 64 and 95 since they are the subnets
; broadcast and multicast addresses not hosts/nodes
65            IN  CNAME   65.64/27.23.168.192.IN_ADDR.ARPA. ;qualified
66            IN  CNAME   66.64/27 ;unqualified name
67            IN  CNAME   67.64/27
....
93            IN  CNAME   93.64/27
94            IN  CNAME   94.64/27
; end of 192.168.23.64/27 subnet
.....
; other subnet definitions

Imaginem que el nostre servidor de l’empresa serà ns1.mydomain.com i que les IPs de l’empresa són 192.168.23.64/27. Doncs bé la gràcia del tema és que quan diu:

64/27 IN NS ns1.mydomain.com.

EL 64/27 NO ÉS UN DIRECCIONAMENT SINÓ UN NOM!!! aquesta era el coi de gràcia. Si mirem altres manuals veurem que a vegades es refereix a la subzona amb “un nom” (qualsevol) que no té res a veure amb la seva direcció de xarxa (com passa a l’exemple). Això feia que em perdés i no sabés que coi havia de posar. Ja que de forma lògica tot semblava indicar que això era una adreça de subnetting no un nom, segons aquest HOWTO, és clar.

Així doncs el meu problema és que el meu DNS superior es referia a aquest “nom” com a 64-27 i no com a 64/27. Per això quan em fallava una resolució em deia, per exemple, que demanava la IP: 192.168.23.64-27.68 i jo no entenia que volia dir això. Doncs bé, quan jo al meu named.conf i al meu fitxer de zona inversa posava 64/27 tal i com indica el manual del que parlo havia de posar 64-27. Ja que ell espera aquest nom, NO ADREÇA DE SUBNETTING. Per això, no hi havia manera d’entendre què estava malament.

Kit-Kat: sé que m’he fet pesat amb tan repetir el mateix, però és que el tema m’ha fet suar molt.

Penseu que si al named.conf indico això:

zone "64/27.23.168.192.in-addr.arpa" in{
	type master;
	file "192.169.23.rev";
};

Sintàcticament és igual de correcte que això altre:

zone "64-27.23.168.192.in-addr.arpa" in{
	type master;
	file "192.169.23.rev";
};

Per això podia llençar el named sense que donès cap error. Que funcioni o que no funcioni, depèn només del que indiqui el nostre DNS superior (el de la zona C). Que en el meu cas no era com l’exemple del HOWTO sinó com el segon cas que he exposat (64-27).

Així doncs el fitxer de zona inversa del HOWTO original comença així:

$ORIGIN 64/27.23.168.192.IN-ADDR.ARPA.
...

Que en el meu cas havia de ser així:

$ORIGIN 64-27.23.168.192.IN-ADDR.ARPA.
...

Ara si que sembla que parli d’una zona quan dic 64-27, doncs no, és un nom!!! en algún manual ho he vist que posava, per exemple: servidor1.23.168.192.IN-ADDR.ARPA. aquesta ha estat la gràcia per arribar a la solució.

Doncs per descobrir aquesta tonteria no sabeu la de dies que m’he passat donant-hi voltes, tampoc i he pogut dedicar ni un dia sencer a pensar en això. Però és clar, quan penses que ho fas tot bé, no dona error i no va… poc més se t’acudeix. Espero que això serveixi perquè ningú més passi pel que he passat jo aquests dies amb aquest problema.

Understanding and Attacking DNS

Reading time: 2 – 2 minutes

dns.gif

The Domain Name System (DNS) is a distributed resource used by most every network application. DNS data is generally trusted implicitly; false data therefore can jeopardize the integrity of network traffic and allow attackers to play manin- the-middle with all traffic. DNS security depends on the client, server, and their respective trust relationship. Securing the trust relationship and building a reliable server can create a reliable and secure DNS structure for the system administrator behind your corporate and private communication requirements. Security of a DNS server varies according to its active role and name resolution requirements. Server responsibilities can be classified as one of three types. Depending on the need of the server, one specific role should be chosen; in particular situations, multiple roles can be supported simultaneously on one physical server. In this shared configuration, authoritative and resolver servers are generally together. Running an individual server for each DNS role is ideal, specifically in a large production environment. After understanding the individual roles and mechanics between each server and experiencing problems individually, an administrator can securely and reliably maintain multiple DNS roles on a single system. DNS security is custom for each type of server, each type of communication, and each common software distribution, all of which will be explained in this article via an in-depth walkthrough.