[Dnsmasq-discuss] Help in DNS amplification attack

@shuToSH Ch@tURveDI ashutosh.chaturvedi.31 at gmail.com
Fri Jul 17 07:26:43 BST 2015


Thanks,

now picture is crystal clear to me thanks for your time and support .



On Fri, Jul 17, 2015 at 11:47 AM, Albert ARIBAUD <albert.aribaud at free.fr>
wrote:

> Bonjour @shuToSH,
>
> Le Fri, 17 Jul 2015 10:34:11 +0530, "@shuToSH Ch at tURveDI"
> <ashutosh.chaturvedi.31 at gmail.com> a écrit :
>
> > as per link i shared they mention
> >
> >
> > in step 3
> > "To test the vulnerability, we will check your server for a DNS record it
> > should not have. If a result is returned, then the info was pulled by
> your
> > server from another DNS server and is open to this vulnerability."
> >
> > yes as i checked capture packet its like my WAN sending some dns query to
> > out internet for 1and1.com and getting result,
> > so on what bases i should reject this result.
>
> The test is for a server hosted in 1and1 and queried from outside its
> LAN.
>
> From what you said, your server is placed in a LAN and queried from
> the same LAN. Therefore it is *not* a 1and1 hosted server and *not*
> queried from outside its LAN.
>
> Therefore the test you are trying to apply is meaningless to you. It
> is meaningful *only* to 1and1 customers.
>
> You are worried that when you do step3 of this test, you see traffic
> between your server and the Internet. Actually, this is perfectly
> normal and if it did not happen, then your server would not function.
> Here's why:
>
> From the LAN, you ask your server to tell you the IP address of
> 1and1.com. Your server looks in its own records. If it has a recent
> enough record for the IP address of 1and1.com, it will return it to
> you. If the record is outdated or does not exist, your server will go
> and ask its upstream server(s) for the IP address of 1and1.com. Once it
> gets the answer, it stores it in its own records and then sends it back
> to you.
>
> Your server only holds a certain number of records, and purges them
> when they get too old, so even if it has 1and1.com in its records at
> some point, later it will purge it and it woll go to the Internet next
> time you ask for it.
>
> And to ask your upstream server(s) and get the answer back, your own
> server *must* send queries and receive answers through the Internet.
> *That* is what you see. If it did not happen, your  server would not be
> able to resolve any query other than for your local network.
>
> This Internet traffic is *normal* and *unrelated to DNS amplification*.
>
> This is an example of why it is important not to apply a test that was
> not designed for your case.
>
> This below is a test which you can apply to your case:
>
> - if your server cannot be queried from the Internet and only talks
>   on the Internet to its upstream server(s), then it *cannot* be used
>   for DNS amplicifation attacks, and that's the end of the test. If your
>   server can be queried from the Internet, then proceed to next item
>   below.
>
> - if your server can be queried from the Internet but is not a name
>   server for a domain you manage, then it is misconfigured and you must
>   reconfigure it to make it unreachable from the Internet, so that it
>   *cannot* be used for DNS amplicifation attacks any more, and that's
>   the end of the test. If your server is a name server for a domain you
>   manage, then proceed to next item below.
>
> - if your server is the name server for a domain you manage, then it
>   *has* to answer queries from the Internet, and therefore it should be
>   protected against being used for DNS ampification attacks. From a
>   dnsmasq user's standpoint, this is basically done by always using the
>   latest version of dnsmasq (and configuring the server properly with
>   respect to the documentation).
>
> > Thanks,
> > AS
>
> Amicalement,
> --
> Albert.
>



-- 

* <http://www.teamf1.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150717/44136e31/attachment.html>


More information about the Dnsmasq-discuss mailing list