[bdNOG] About google.com.bd

Kabindra Shrestha kabindra at geeks.net.np
Tue Dec 20 17:30:12 BDT 2016


> On Dec 20, 2016, at 4:57 PM, Sumon Ahmed Sabir <sumon at fiberathome.net> wrote:
> 
> 
> Got the actual fact. The WebFront end of the .BD was compromised. So hacker changed some DNS record via that.
> At this moment it seems fixed.

That's what I thought.

Great work Sumon da.

Thanks.
 -kabindra

> 
> 
> -sumon
> 
> Sumons-MacBook-Air:~ sumon$ host -vt ns google.com.bd dns.bd
> 
> Trying "google.com.bd"
> 
> Using domain server:
> 
> Name: dns.bd
> 
> Address: 2407:5000:88:5::3#53
> 
> Aliases:
> 
> 
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48765
> 
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> 
> 
> 
> ;; QUESTION SECTION:
> 
> ;google.com.bd.	IN	NS
> 
> 
> 
> ;; AUTHORITY SECTION:
> 
> google.com.bd.	86400	IN	NS	ns4.google.com.
> 
> google.com.bd.	86400	IN	NS	ns2.google.com.
> 
> google.com.bd.	86400	IN	NS	ns3.google.com.
> 
> 
> 
> Received 95 bytes from 2407:5000:88:5::3#53 in 1003 ms
> 
> Sumons-MacBook-Air:~ sumon$ host -vt ns google.com.bd surma.btcl.net.bd
> 
> Trying "google.com.bd"
> 
> Using domain server:
> 
> Name: surma.btcl.net.bd
> 
> Address: 203.112.194.232#53
> 
> Aliases:
> 
> 
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14716
> 
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> 
> 
> 
> ;; QUESTION SECTION:
> 
> ;google.com.bd.	IN	NS
> 
> 
> 
> ;; AUTHORITY SECTION:
> 
> google.com.bd.	86400	IN	NS	ns4.google.com.
> 
> google.com.bd.	86400	IN	NS	ns2.google.com.
> 
> google.com.bd.	86400	IN	NS	ns3.google.com.
> 
> 
> 
> Received 95 bytes from 203.112.194.232#53 in 192 ms
> 
> Sumons-MacBook-Air:~ sumon$ host -vt ns google.com.bd surma.btcl.net.bd
> 
> Trying "google.com.bd"
> 
> Using domain server:
> 
> Name: surma.btcl.net.bd
> 
> Address: 203.112.194.232#53
> 
> Aliases:
> 
> 
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50416
> 
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> 
> 
> 
> ;; QUESTION SECTION:
> 
> ;google.com.bd.	IN	NS
> 
> 
> 
> ;; AUTHORITY SECTION:
> 
> google.com.bd.	86400	IN	NS	ns4.google.com.
> 
> google.com.bd.	86400	IN	NS	ns2.google.com.
> 
> google.com.bd.	86400	IN	NS	ns3.google.com.
> 
> 
> 
> Received 95 bytes from 203.112.194.232#53 in 214 ms
> 
> 
> On Tue, 20 Dec 2016 at 16:13 Kabindra Shrestha <kabindra at geeks.net.np> wrote:
> Wow, they manage to change it again.
> 
> Like I mentioned in my previous mail to the list, I strongly believe it is their master server or registry portal that is compromised and they should temporarily disable their domain registry portal to further analyse into it, along with filtering the access.
> They seem to have updated the filter but they have also updated DNS filter and I can confirm (since we also slave com.bd) we no longer are able to do the zone transfer, so that is the reason that you are not seeing two of the servers with fake NS list.
> 
> $ dig @x.x.x.x axfr com.bd
> 
> ; <<>> DiG 9.9.9-P3 <<>> @ x.x.x.x axfr com.bd
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> If you see, the nameserver for .COM.BD are now carrying varying serials.
> 
> $ dig +nssearch com.bd
> SOA dns.bd. root.dns.bd. 2016122031 14400 3600 604800 86400 from server 204.61.216.108 in 3 ms.
> SOA dns.bd. root.dns.bd. 2016122031 14400 3600 604800 86400 from server 209.58.24.3 in 376 ms.
> SOA dns.bd. root.dns.bd. 2016122036 14400 3600 604800 86400 from server 203.112.194.231 in 386 ms.
> SOA dns.bd. root.dns.bd. 2016122036 14400 3600 604800 86400 from server 203.112.194.232 in 550 ms
> 
>  for n in `dig ns com.bd +short`; do echo $n; dig @$n soa com.bd +short; echo ; done
> dns.bd.
> dns.bd. root.dns.bd. 2016122031 14400 3600 604800 86400
> 
> bd-ns.anycast.pch.net.
> dns.bd. root.dns.bd. 2016122031 14400 3600 604800 86400
> 
> surma.btcl.net.bd.
> dns.bd. root.dns.bd. 2016122035 14400 3600 604800 86400
> 
> jamuna.btcl.net.bd.
> dns.bd. root.dns.bd. 2016122035 14400 3600 604800 86400
> 
> 
> Only reverting back to the original content will not help solve this problem, they have to analyse and figure out the loophole.
> 
> Thanks.
>  -kabindra
> 
> 
> > On Dec 20, 2016, at 3:01 PM, Brian Candler <brian at nsrc.org> wrote:
> >
> > On 20/12/2016 05:33, Omar Ali wrote:
> >> Please someone help BTCL to fix NS record to actual NS
> >
> > The replies from the BD nameservers are inconsistent:
> >
> > $ dig +norec @surma.btcl.net.bd. google.com.bd. a | grep NS
> > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
> > google.com.bd.        86400    IN    NS    ns2.phpvibe.net.
> > google.com.bd.        86400    IN    NS    ns1.phpvibe.net.
> >
> > $ dig +norec @jamuna.btcl.net.bd. google.com.bd. a | grep NS
> > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
> > google.com.bd.        86400    IN    NS    ns2.phpvibe.net.
> > google.com.bd.        86400    IN    NS    ns1.phpvibe.net.
> >
> > $ dig +norec @dns.bd. google.com.bd. a | grep NS
> > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> > google.com.bd.        86400    IN    NS    ns2.google.com.
> > google.com.bd.        86400    IN    NS    ns3.google.com.
> > google.com.bd.        86400    IN    NS    ns4.google.com.
> >
> > I should also check whether the addresses of the nameservers themselves have been poisoned. Here (UK) I get:
> >
> > $ dig +short surma.btcl.net.bd
> > 203.112.194.232
> > $ dig +short jamuna.btcl.net.bd
> > 203.112.194.231
> > $ dig +short dns.bd
> > 209.58.24.3
> >
> > That looks correct - at least it agrees with the glue records returned by the root nameservers:
> >
> > ;; ADDITIONAL SECTION:
> > dns.bd.            172800    IN    A    209.58.24.3
> > surma.btcl.net.bd.    172800    IN    A    203.112.194.232
> > jamuna.btcl.net.bd.    172800    IN    A    203.112.194.231
> >
> > So the most likely thing is that two of those three bd. nameservers have been attacked somehow   It doesn't look like cache poisoning; they are giving authoritative answers pointing to ns{1,2}.phpvibe.net
> >
> > Regards,
> >
> > Brian.
> > _______________________________________________
> > nog mailing list
> > nog at bdnog.org
> > http://mailman.bdnog.org/mailman/listinfo/nog
> 
> _______________________________________________
> nog mailing list
> nog at bdnog.org
> http://mailman.bdnog.org/mailman/listinfo/nog

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20161220/de205cb4/attachment.pgp>


More information about the nog mailing list