RE: DNS ACL ?

From: John Hally (JHally_at_epnet.com)
Date: 11/26/05

  • Next message: Erin Carroll: "Moving from Defense to Offense (or vice versa) to secure your network"
    To: "'Dario Ciccarone (dciccaro)'" <dciccaro@cisco.com>, Kyle Quest <Kyle.Quest@networkengines.com>, pen-test@securityfocus.com
    Date: Sat, 26 Nov 2005 10:30:08 -0500
    
    

    Thanks Dario for all of the information.

    I'm the original poster, and there should be no zone transfers coming in
    from the internet to these servers. At first glance it looks like a
    no-brainer, deny tcp/53 for zone transfers and allow udp/53 for queries, but
    then comes the nebulous 'stuff' that you've pointed out.

    I think I'm looking at two options really, deny tcp/53 and see if anything
    breaks, or allow tcp-udp/53 and limit zone transfers to known hosts (which
    we do anyway), and just make sure I have the systems hardened as well as
    they can be.

    I really appreciate the info provided, its good food for thought. DNS
    always seems to bring about interesting discussions.

    Thanks again,

    John.

    -----Original Message-----
    From: Dario Ciccarone (dciccaro) [mailto:dciccaro@cisco.com]
    Sent: Wednesday, November 23, 2005 4:00 PM
    To: Kyle Quest; pen-test@securityfocus.com
    Subject: RE: DNS ACL ?

    > >RFC-2671 ('Extension Mechanisms for DNS (EDNS0)') updates
    > RFC-2671 and
    > >allows for packet sizes > 512 when using UDP as transport.
    > >
    > >A reference from MS: http://support.microsoft.com/kb/828263
    > >
    > >Some queries that might exceed the 512-byte size are those like, for
    > >example, www.microsoft.com or www.yahoo.com, due to the number of A
    > >records returned.
    > >
    > >So, you will probably be OK with only allowing 53/udp to your DNS
    > >server.
    >
    > That's not always true. Yes, DNS extensions have a mechanism to
    > increase the UDP message size. However, both sides (clients
    > and servers)
    > are involved in the process of negotiating those big messages.
    > Not all DNS clients automatically try to negotiate bigger UDP
    > messages. The same goes for DNS servers. And there's always security
    > devices somewhere on the network that may not allow those
    > extensions...
    > either by stripping or disallowing the udp message size option or
    > simply by ignoring (/not understanding) them. My recommendation is
    > to not rely on any extended DNS functionality.
    >
    > Kyle

    That's true - as an example, PIX firewalls pre 6.3(2) only allowed DNS
    UDP traffic <= 512.

    So, back to the start. RFC-1035 - section 4.2. Transport, subsection
    4.2.1. UDP usage :

    "Messages sent using UDP user server port 53 (decimal).

    Messages carried by UDP are restricted to 512 bytes (not counting the IP
    or UDP headers). Longer messages are truncated and the TC bit is set in
    the header."

    So far, so good. Then RFC-2181 - "Clarifications to the DNS
    Specification", section "9. The TC (truncated) header bit":

    "
    9. The TC (truncated) header bit

       The TC bit should be set in responses only when an RRSet is required
       as a part of the response, but could not be included in its entirety.
       The TC bit should not be set merely because some extra information
       could have been included, but there was insufficient room. This
       includes the results of additional section processing. In such cases
       the entire RRSet that will not fit in the response should be omitted,
       and the reply sent as is, with the TC bit clear. If the recipient of
       the reply needs the omitted data, it can construct a query for that
       data and send that separately.

       Where TC is set, the partial RRSet that would not completely fit may
       be left in the response. When a DNS client receives a reply with TC
       set, it should ignore that response, and query again, using a
       mechanism, such as a TCP connection, that will permit larger replies.
    "

    Key things to keep in mind here - RFC-2181 is a "Proposed Standard".
    Also, from RFC-2119, "Key words for use in RFCs to Indicate Requirement
    Levels":

    "
    3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.
    "

    So, the whole 'query over TCP if TC set' is a 'should' - not a 'must'.
    Same goes for EDNS0. Many resolver implementations are probably doing it
    - while there could be others that don't, or devices that just plain not
    process TCP/53 as queries, but only as zone transfers.

    Leaving the whole RFC mumbo-jumbo aside, my point is simple: as with any
    other security setup, you shouldn't allow traffic into your network that
    isn't strictly required. So if the original poster does NOT need to
    allow 53/TCP to his/her DNS server, because he's absolutely, positively
    sure the replies are never going to be > 512 bytes . . . Why would he
    allow it then?

    Dario

    ----------------------------------------------------------------------------

    --
    Audit your website security with Acunetix Web Vulnerability Scanner: 
    Hackers are concentrating their efforts on attacking applications on your 
    website. Up to 75% of cyber attacks are launched on shopping carts, forms, 
    login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
    futile against web application hacking. Check your website for
    vulnerabilities 
    to SQL injection, Cross site scripting and other web attacks before hackers
    do! 
    Download Trial at:
    http://www.securityfocus.com/sponsor/pen-test_050831
    ----------------------------------------------------------------------------
    ---
    ------------------------------------------------------------------------------
    Audit your website security with Acunetix Web Vulnerability Scanner: 
    Hackers are concentrating their efforts on attacking applications on your 
    website. Up to 75% of cyber attacks are launched on shopping carts, forms, 
    login pages, dynamic content etc. Firewalls, SSL and locked-down servers are 
    futile against web application hacking. Check your website for vulnerabilities 
    to SQL injection, Cross site scripting and other web attacks before hackers do! 
    Download Trial at:
    http://www.securityfocus.com/sponsor/pen-test_050831
    -------------------------------------------------------------------------------
    

  • Next message: Erin Carroll: "Moving from Defense to Offense (or vice versa) to secure your network"

    Relevant Pages

    • Re: transferring secondary DNS zone problem
      ... All the servers involved are W2K3. ... IPs in as DNS forwarders and allowed zone transfers. ...
      (microsoft.public.windows.server.dns)
    • Re: Zone Transfer and Trust
      ... > local AD Integrated DNS servers at both locations? ... Herb Martin ... >>> Do we need to do Zone transfers from one DNS to another DNS to ...
      (microsoft.public.windows.server.dns)
    • RE: DNS ACL ?
      ... > Not all DNS clients automatically try to negotiate bigger UDP ... The same goes for DNS servers. ... as a part of the response, but could not be included in its entirety. ...
      (Pen-Test)
    • RE: Pubstro rash
      ... As far as I'm concerned DNS just uses 53/TCP to do zone transfers. ... Tipically zone transfers would only be used by secondary servers to update ... Cipher - Segurança da Informação ...
      (Incidents)
    • Re: Zone Transfer and Trust
      ... > Do we need to do Zone transfers from one DNS to another DNS to establish a ... ALL machines must be WINS servers clients, ... can't a one way trust be ... Zone transfers need to take place to all DNS secondary ...
      (microsoft.public.windows.server.dns)

  • Quantcast