Criado Indomable

Un intento de Blog de Sebastián D. Criado – 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

La misteriosa consulta desde 127.0.0.2

Posted by Sebastián Criado en Viernes, enero 19, 2007 13:05

SeguridadEn uno de los servidores que administro, me encontré con múltiples consultas al DNS (BIND) desde 127.0.0.2:53 y las mismas eran rechazadas por el bin dado que está configurado para aceptar solo peticiones de la red interna y de 127.0.0.1 (localhost).
Luego de un análisis exhaustivo, pude determinar el problema y solucionarlo, aunque me quedaron algunas dudas respecto a por que se efectúan las consultas desde esa IP.

El problema comenzó a reportarse cuando el named informaba el rechazo de la consulta a través del syslog, reportando en forma reiterativa el siguiente mensaje:
named[17111]: refused query on non-query socket from [127.0.0.2].53
Esto me indicaba, como dice el mensaje, que se estaba haciendo un query al DNS desde la dirección 127.0.0.2:53

Sabiendo que estaba bien que sea rechazado el pedido, me dispuse a ver que era lo que estaba originando el mismo.

Lo que me encontré me llevo al problema directamente.

La IP 127.0.0.2 es utilizada por los sistemas de RBL para informar que la ip que se le ha consultado (ej: 200.69.206.108) está dentro de su base de datos como una ip bloqueada.

La forma de comprobarlo es hacer una consulta por medio de dig sobre una ip en la forma inversa. Para eso tome un servidor de RBL que se que funciona de la empresa Impsat de Chile.
http://abuse.impsat.cl/

Al hacerle una consulta a sus DNS sobre la IP 200.69.206.108 obtendremos el siguiente resultado:
$ dig a @dns.impsat.cl 108.206.69.200.abuse.impsat.cl
;; ANSWER SECTION:
108.206.69.200.abuse.impsat.cl. 3600 IN A 127.0.0.2

Como se puede ver, nos responde la ip del problema.

¿Pero que tiene que ver esto con el problema de los mensajes del bind?

Para poder chequear desde el Sendmail si una ip esta dentro de una RBL se puede utilizar DNSBL. Este sistema va hacer una serie de pasos para comprobar si el mail que está entrando se encuentra en la RBL que se le ha consultado consultar.

En este caso, estaba usando la RBL relay.ordb.org configurada en el Sendmail.

Dado que relay.ordb.org cerro a fin de este año, no se podía hacer la consulta, las consultas que DNSBL le enviaba no se podían responder.
Una vez removida la línea del sendmail.mc y generado el cf correspondiente, el mensaje dejo de aparecer. Problema resuelto. Pero aun me quedaba una duda, dado que el que efectuaba el pedido a 127.0.0.2 era el mismo bind.

Así, sabiendo que relays.ordb.org no funcionaba, me dispuse a hacer la consulta por medio del dig usando ese servidor, y por medio de tcpdump mire que pasada en la interfase “lo”.
$ dig @relays.ordb.org 108.206.69.200.relays.ordb.org

El resultado de tcpdump de los pedidos fue el siguiente:
15:36:34.475690 127.0.0.1.45816 > 127.0.0.1.53: 2733+ A? relays.ordb.org. (33) (DF)

En está linea se puede ver la consulta al DNS sobre el dominio consultado para así poder determinar su IP.
15:36:40.003493 127.0.0.2.53 > 127.0.0.2.53: 65036 A? relays.ordb.org. (33) (DF)
15:36:42.003496 127.0.0.2.53 > 127.0.0.2.53: 56582 [1au] A? relays.ordb.org. OPT UDPsize=4096 (44) (DF)

Inmediatamente después se ve una consulta desde 127.0.0.2 a si mismo.
15:36:42.003592 127.0.0.1.53 > 127.0.0.1.45812: 32447 ServFail 0/0/0 (33) (DF)

La respuesta que le llega es un ServFail al no poder determinar la ip del mismo.
15:36:42.003624 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45812 unreachable [tos 0xc0]
15:36:48.503386 127.0.0.1.45816 > 127.0.0.1.53: 2733+ A? relays.ordb.org. (33) (DF)
15:36:56.003425 127.0.0.1.53 > 127.0.0.1.45814: 60805 ServFail 0/0/0 (33) (DF)
15:36:56.003480 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45814 unreachable [tos 0xc0]
15:37:02.003500 127.0.0.2.53 > 127.0.0.2.53: 56582 A? relays.ordb.org. (33) (DF)
15:37:02.534023 127.0.0.1.45818 > 127.0.0.1.53: 2734+ A? relays.ordb.org. (33) (DF)
15:37:10.003491 127.0.0.2.53 > 127.0.0.2.53: 56582 A? relays.ordb.org. (33) (DF)
15:37:10.003589 127.0.0.2.53 > 127.0.0.2.53: 34326 [1au] A? relays.ordb.org. OPT UDPsize=4096 (44) (DF)
15:37:16.563394 127.0.0.1.45818 > 127.0.0.1.53: 2734+ A? relays.ordb.org. (33) (DF)
15:37:26.003490 127.0.0.1.53 > 127.0.0.1.45816: 2733 ServFail 0/0/0 (33) (DF)
15:37:26.003537 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45816 unreachable [tos 0xc0]
15:37:30.003488 127.0.0.2.53 > 127.0.0.2.53: 34326 A? relays.ordb.org. (33) (DF)
15:37:38.003423 127.0.0.2.53 > 127.0.0.2.53: 34326 A? relays.ordb.org. (33) (DF)

Las demás lineas, muestran idéntico resultado en los reintentos hasta que se regresa un “Temporary failure in name resolution” al no poder resolverlo.

Intente reproducir el problema con otros dominios los cuales no existen y no pude obtener estos resultados.

La hipótesis sobre esto es:

Dado que para poder ser un RBL se tendrá que hacer una implementación que antes una consulta de DNS responda con 127.0.0.2 para informar que la ip figura en la base de datos, pero dado que el servicio de rbl de relays.ordb.org no está funcionando, el DNS de este servidor está respondiendo a todas las consultas con un 127.0.0.2 y el dns de mi servidor trata de atenderlo como un pedido de loopback.

Esta hipótesis tiene el problema que no puedo comprobarlo ya que no tengo acceso a la configuración actual de relays.ordb.org, pero si entiendo que usan un sistema tipo rbldn para brindar el servicio.

¿Alguna idea?

9 comentarios to “La misteriosa consulta desde 127.0.0.2”

  1. Alfrenovsky said

    En el firewall hay que abrir dev lo completo.
    localhost no es 127.0.0.1, es toda las res 127.0.0.0/8

  2. No es que el firewall lo este filtrando.
    La pregunta es por que hace esa consulta.

  3. Te doy la pista: man nsswitch.conf

  4. […] No importa cual sea, postfix, sendmail o qmail, si tenías relays.ordb.org configurado, se rechazarán los mails de todo el mundo. […]

  5. Jorge said

    Alguien podria mencionar el comando para poder remover esta configuración y asi lograr permitir el paso de los correos, me esta llevando muchos problemas esa configuración.

  6. Depende del servidor de correos que tengas.

  7. […] El año pasado el servicio de relays.ordb.org dejo de estar accesible con lo cual, lo único que se obtenía era una larga lista de logs en los servidores de correo indicando que no fusionaba y hasta algunas misteriosas consultas al loopback. […]

  8. […] El año pasado el servicio de relays.ordb.org dejo de estar accesible con lo cual, lo único que se obtenía era una larga lista de logs en los servidores de correo indicando que no funcionaba y hasta algunas misteriosas consultas al loopback. […]

  9. […] El año pasado el servicio de relays.ordb.org dejo de estar accesible con lo cual, lo único que se obtenía era una larga lista de logs en los servidores de correo indicando que no funcionaba y hasta algunas misteriosas consultas al loopback. […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: