[LUG.ro] La misteriosa consulta desde 127.0.0.2

Alberto Jorge Cushnir lugro@lugro.org.ar
Wed, 17 Jan 2007 16:22:33 -0300


------=_Part_96366_2916385.1169061753527
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Seba,

Aqui te posteo la direccion de un draft que explica sobre el tema (esta en
ingles):

http://tools.ietf.org/group/irtf/draft-irtf-asrg-dnsbl-02.txt

Espero sea de utilidad



2007/1/17, Sebasti=E1n D. Criado <scriado@ciudad.com.ar>:
>
> En uno de los servidores que administro, me encontr=E9 con con m=FAltiple=
s
> consultas al DNS (BIND) desde 127.0.0.2:53 y las mismas eran rechazadas
> por
> el bind dado que est=E1 configurado mediante ACL's para aceptar solo
> peticiones
> de la red interna y de 127.0.0.1 (localhost).
> Luego de un an=E1lisis exhaustivo, pude determinar el problema y
> solucionarlo,
> aunque me quedaron algunas dudas respecto a por que se  efect=FAan las
> consultas desde esa IP.
>
> El problema comenz=F3 a reportarse cuando el BIND infrmaba el rechazo de =
la
> consulta a trav=E9s del syslog, reportando en forma reiterativa el siguie=
nte
> 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 a=
l
> DNS
> desde la direcci=F3n 127.0.0.2:53
>
> Sabiendo que estaba bien que sea rechazado el pedido, me dispuse a ver qu=
e
> era
> lo que estaba originando el mismo.
>
> Lo que me encontr=E9 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=E1 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
> como
> el  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.
>
> =BFPero 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 lo
> que
> se puede utilizar en DNSBL http://en.wikipedia.org/wiki/DNSBL. Este
> sistema
> va hacer una serie de pasos para comprobar si el mail que est=E1 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=F1o, no se pod=EDa hacer la
> consulta, las consultas que DNSBL le enviaba no se pod=EDan responder.
> Una vez removida la linea 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=ED, 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=E1 linea se puede ver la consulta al DNS sobre el dominio consulta=
do
> para
> as=ED 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=3D4096 (44) (DF)
>
> Inmediatamente despu=E9s 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=3D4096 (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=E1s lineas, muestran id=E9ntico resultado en los reintentos.
>
> Intente reproducir el problema con otros dominios los cuales no existen y
> no
> pude obtener estos resultados.
>
> La hip=F3tesis sobre esto es:
>
> Dado que para poder ser un RBL se tendr=E1 que hacer una implementaci=F3n=
 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=E1 funcionando, el DNS de este servidor est=E1
> 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=F3tesis tiene el problema que no puedo comprobarlo ya que no ten=
go
> acceso a la configuraci=F3n actual de relays.ordb.org, pero si enteiendo =
que
> usan un sistema tipo rbldn http://www.ladro.com/docs/dns/rblsmtpd.htmlpar=
a
> brindar el servicio.
>
> =BFAlguna idea sobre esto? =BFA alguno le a pasado? =BFPor que hace mi DN=
S
> consultas
> desde 127.0.0.2 cuando no tendr=EDa que hacerlas?
>
>
> --
>
> Sebasti=E1n D. Criado - scriado{en}ciudad.com.ar
> L.U.G.R.o - http://www.lugro.org.ar
> GNU/Linux Registered User # 146768
> -------------------------------------------------------------------
> "Si el Universo fuera un programa estar=EDa hecho en C, y correr=EDa sobr=
e
> un sistema UNIX"
>                                                    An=F3nimo.
>
>
>
>
>

------=_Part_96366_2916385.1169061753527
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Seba,<br><br>Aqui te posteo la direccion de un draft que explica sobre el t=
ema (esta en ingles):<br><br><a href=3D"http://tools.ietf.org/group/irtf/dr=
aft-irtf-asrg-dnsbl-02.txt">http://tools.ietf.org/group/irtf/draft-irtf-asr=
g-dnsbl-02.txt
</a><br><br>Espero sea de utilidad<br><br><br><br><div><span class=3D"gmail=
_quote">2007/1/17, Sebasti=E1n D. Criado &lt;<a href=3D"mailto:scriado@ciud=
ad.com.ar">scriado@ciudad.com.ar</a>&gt;:</span><blockquote class=3D"gmail_=
quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt =
0pt 0.8ex; padding-left: 1ex;">
En uno de los servidores que administro, me encontr=E9 con con m=FAltiples<=
br>consultas al DNS (BIND) desde <a href=3D"http://127.0.0.2:53">127.0.0.2:=
53</a> y las mismas eran rechazadas por<br>el bind dado que est=E1 configur=
ado mediante ACL&#39;s para aceptar solo peticiones
<br>de la red interna y de <a href=3D"http://127.0.0.1">127.0.0.1</a> (loca=
lhost).<br>Luego de un an=E1lisis exhaustivo, pude determinar el problema y=
 solucionarlo,<br>aunque me quedaron algunas dudas respecto a por que se&nb=
sp;&nbsp;efect=FAan las
<br>consultas desde esa IP.<br><br>El problema comenz=F3 a reportarse cuand=
o el BIND infrmaba el rechazo de la<br>consulta a trav=E9s del syslog, repo=
rtando en forma reiterativa el siguiente<br>mensaje:<br><br>named[17111]: r=
efused query on non-query socket from [
<a href=3D"http://127.0.0.2">127.0.0.2</a>].53<br><br>Esto me indicaba, com=
o dice el mensaje, que se estaba haciendo un query al DNS<br>desde la direc=
ci=F3n <a href=3D"http://127.0.0.2:53">127.0.0.2:53</a><br><br>Sabiendo que=
 estaba bien que sea rechazado el pedido, me dispuse a ver que era
<br>lo que estaba originando el mismo.<br><br>Lo que me encontr=E9 me llevo=
 al problema directamente.<br><br>La IP <a href=3D"http://127.0.0.2">127.0.=
0.2</a> es utilizada por los sistemas de RBL para informar que la ip<br>que=
 se le ha consultado (ej:=20
<a href=3D"http://200.69.206.108">200.69.206.108</a>) est=E1 dentro de su b=
ase de datos<br>como una ip bloqueada.<br><br>La forma de comprobarlo es ha=
cer una consulta por medio de dig sobre una ip en<br>la forma inversa. Para=
 eso tome un servidor de RBL que se que funciona como
<br>el&nbsp;&nbsp;empresa Impsat de Chile.<br><a href=3D"http://abuse.impsa=
t.cl/">http://abuse.impsat.cl/</a><br><br>Al hacerle una consulta a sus DNS=
 sobre la IP <a href=3D"http://200.69.206.108">200.69.206.108</a> obtendrem=
os el<br>siguiente resultado:
<br><br>$ dig a @<a href=3D"http://dns.impsat.cl">dns.impsat.cl</a> <a href=
=3D"http://108.206.69.200.abuse.impsat.cl">108.206.69.200.abuse.impsat.cl</=
a><br><br>;; ANSWER SECTION:<br><a href=3D"http://108.206.69.200.abuse.imps=
at.cl">
108.206.69.200.abuse.impsat.cl</a>. 3600 IN A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; <a href=3D"http://127.0.0.2">127.0.0.2</a><br><br>Como se puede ver,=
 nos responde la ip del problema.<br><br>=BFPero que tiene que ver esto con=
 el problema de los mensajes del bind?
<br><br>Para poder chequear desde el Sendmail si una ip esta dentro de una =
RBL lo que<br>se puede utilizar en DNSBL <a href=3D"http://en.wikipedia.org=
/wiki/DNSBL">http://en.wikipedia.org/wiki/DNSBL</a>. Este sistema<br>va hac=
er una serie de pasos para comprobar si el mail que est=E1 entrando se
<br>encuentra en&nbsp;&nbsp;la RBL que se le ha consultado consultar.<br><b=
r>En este caso, estaba usando la RBL <a href=3D"http://relay.ordb.org">rela=
y.ordb.org</a> configurada en el Sendmail.<br><br>Dado que <a href=3D"http:=
//relay.ordb.org">
relay.ordb.org</a> cerro a fin de este a=F1o, no se pod=EDa hacer la<br>con=
sulta, las consultas que DNSBL le enviaba no se pod=EDan responder.<br>Una =
vez removida la linea del <a href=3D"http://sendmail.mc">sendmail.mc</a> y =
generado el cf correspondiente, el
<br>mensaje dejo de aparecer. Problema resuelto. Pero aun me quedaba una du=
da,<br>dado que el que efectuaba el pedido a <a href=3D"http://127.0.0.2">1=
27.0.0.2</a> era el mismo bind.<br><br>As=ED, sabiendo que <a href=3D"http:=
//relays.ordb.org">
relays.ordb.org</a> no funcionaba, me dispuse a hacer la<br>consulta por me=
dio del dig usando ese servidor, y por medio de tcpdump mire<br>que pasada =
en la interfase "lo".<br><br>$ dig @<a href=3D"http://relays.ordb.org">rela=
ys.ordb.org
</a> <a href=3D"http://108.206.69.200.relays.ordb.org">108.206.69.200.relay=
s.ordb.org</a><br><br>El resultado de&nbsp;&nbsp;tcpdump de los pedidos fue=
 el siguiente:<br><br>15:36:34.475690 127.0.0.1.45816 &gt; 127.0.0.1.53:&nb=
sp;&nbsp;2733+ A?=20
<a href=3D"http://relays.ordb.org">relays.ordb.org</a>.<br>(33) (DF)<br><br=
>En est=E1 linea se puede ver la consulta al DNS sobre el dominio consultad=
o para<br>as=ED poder determinar su IP.<br><br>15:36:40.003493 127.0.0.2.53=
 &gt;=20
127.0.0.2.53:&nbsp;&nbsp;65036 A? <a href=3D"http://relays.ordb.org">relays=
.ordb.org</a>. (33)<br>(DF)<br>15:36:42.003496 127.0.0.2.53 &gt; 127.0.0.2.=
53:&nbsp;&nbsp;56582 [1au] A? <a href=3D"http://relays.ordb.org">relays.ord=
b.org</a>.<br>OPT&nbsp;&nbsp;UDPsize=3D4096 (44) (DF)
<br><br>Inmediatamente despu=E9s se ve una consulta desde <a href=3D"http:/=
/127.0.0.2">127.0.0.2</a> a si mismo.<br><br>15:36:42.003592 127.0.0.1.53 &=
gt; 127.0.0.1.45812:&nbsp;&nbsp;32447 ServFail 0/0/0 (33)<br>(DF)<br><br>La=
 respuesta que le llega es un ServFail al no poder determinar la ip del
<br>mismo.<br><br>15:36:42.003624 <a href=3D"http://127.0.0.1">127.0.0.1</a=
> &gt; <a href=3D"http://127.0.0.1">127.0.0.1</a>: icmp: <a href=3D"http://=
127.0.0.1">127.0.0.1</a> udp port 45812<br>unreachable [tos 0xc0]<br>15:36:=
48.503386
 127.0.0.1.45816 &gt; 127.0.0.1.53:&nbsp;&nbsp;2733+ A? <a href=3D"http://r=
elays.ordb.org">relays.ordb.org</a>.<br>(33) (DF)<br>15:36:56.003425 127.0.=
0.1.53 &gt; 127.0.0.1.45814:&nbsp;&nbsp;60805 ServFail 0/0/0 (33)<br>(DF)<b=
r>15:36:56.003480=20
<a href=3D"http://127.0.0.1">127.0.0.1</a> &gt; <a href=3D"http://127.0.0.1=
">127.0.0.1</a>: icmp: <a href=3D"http://127.0.0.1">127.0.0.1</a> udp port =
45814<br>unreachable [tos 0xc0]<br>15:37:02.003500 127.0.0.2.53 &gt; 127.0.=
0.2.53
:&nbsp;&nbsp;56582 A? <a href=3D"http://relays.ordb.org">relays.ordb.org</a=
>. (33)<br>(DF)<br>15:37:02.534023 127.0.0.1.45818 &gt; 127.0.0.1.53:&nbsp;=
&nbsp;2734+ A? <a href=3D"http://relays.ordb.org">relays.ordb.org</a>.<br>(=
33) (DF)<br>15:37:10.003491
 127.0.0.2.53 &gt; 127.0.0.2.53:&nbsp;&nbsp;56582 A? <a href=3D"http://rela=
ys.ordb.org">relays.ordb.org</a>. (33)<br>(DF)<br>15:37:10.003589 127.0.0.2=
.53 &gt; 127.0.0.2.53:&nbsp;&nbsp;34326 [1au] A? <a href=3D"http://relays.o=
rdb.org">relays.ordb.org
</a>.<br>OPT&nbsp;&nbsp;UDPsize=3D4096 (44) (DF)<br>15:37:16.563394 127.0.0=
.1.45818 &gt; 127.0.0.1.53:&nbsp;&nbsp;2734+ A? <a href=3D"http://relays.or=
db.org">relays.ordb.org</a>.<br>(33) (DF)<br>15:37:26.003490 127.0.0.1.53 &=
gt; 127.0.0.1.45816:&nbsp;&nbsp;2733 ServFail 0/0/0 (33) (DF)
<br>15:37:26.003537 <a href=3D"http://127.0.0.1">127.0.0.1</a> &gt; <a href=
=3D"http://127.0.0.1">127.0.0.1</a>: icmp: <a href=3D"http://127.0.0.1">127=
.0.0.1</a> udp port 45816<br>unreachable [tos 0xc0]<br>15:37:30.003488 127.=
0.0.2.53
 &gt; 127.0.0.2.53:&nbsp;&nbsp;34326 A? <a href=3D"http://relays.ordb.org">=
relays.ordb.org</a>. (33)<br>(DF)<br>15:37:38.003423 127.0.0.2.53 &gt; 127.=
0.0.2.53:&nbsp;&nbsp;34326 A? <a href=3D"http://relays.ordb.org">relays.ord=
b.org</a>. (33)<br>(DF)
<br><br>Las dem=E1s lineas, muestran id=E9ntico resultado en los reintentos=
.<br><br>Intente reproducir el problema con otros dominios los cuales no ex=
isten y no<br>pude obtener estos resultados.<br><br>La hip=F3tesis sobre es=
to es:
<br><br>Dado que para poder ser un RBL se tendr=E1 que hacer una implementa=
ci=F3n que<br>antes una consulta de DNS responda con <a href=3D"http://127.=
0.0.2">127.0.0.2</a> para informar que la ip<br>figura en la base de datos,=
 pero dado que el servicio de rbl de
<br><a href=3D"http://relays.ordb.org">relays.ordb.org</a> no est=E1 funcio=
nando, el DNS de este servidor est=E1<br>respondiendo a todas las consultas=
 con un <a href=3D"http://127.0.0.2">127.0.0.2</a> y el dns de mi servidor<=
br>trata de atenderlo como un pedido de loopback.
<br><br>Esta hip=F3tesis tiene el problema que no puedo comprobarlo ya que =
no tengo<br>acceso a la configuraci=F3n actual de <a href=3D"http://relays.=
ordb.org">relays.ordb.org</a>, pero si enteiendo que<br>usan un sistema tip=
o rbldn=20
<a href=3D"http://www.ladro.com/docs/dns/rblsmtpd.html">http://www.ladro.co=
m/docs/dns/rblsmtpd.html</a> para<br>brindar el servicio.<br><br>=BFAlguna =
idea sobre esto? =BFA alguno le a pasado? =BFPor que hace mi DNS consultas<=
br>desde=20
<a href=3D"http://127.0.0.2">127.0.0.2</a> cuando no tendr=EDa que hacerlas=
?<br><br><br>--<br><br>Sebasti=E1n D. Criado - scriado{en}ciudad.com.ar<br>=
L.U.G.R.o - <a href=3D"http://www.lugro.org.ar">http://www.lugro.org.ar</a>=
<br>
GNU/Linux Registered User # 146768<br>-------------------------------------=
------------------------------<br>&quot;Si el Universo fuera un programa es=
tar=EDa hecho en C, y correr=EDa sobre<br>un sistema UNIX&quot;<br>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An=F3ni=
mo.
<br><br><br><br><br></blockquote></div><br>

------=_Part_96366_2916385.1169061753527--