Re: IBM i DNS vs DNS Zone Transfer threat

[Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx>]

Hey Larry, just curious... does it also now support views? And is that 
in the GUI?

On 02/16/2011 05:05 PM, DrFranken wrote:
> I DO use IBM i for DNS and it DOES support the acl. It's all in the GUI
> configuration as well and as usual it works.
>
>           - Larry
>
> On 2/16/2011 4:12 PM, Bruce Hoffman wrote:
> > I don't use IBM i for DNS, but IIRC, 7.1 is now bind 9.x, so...
> >
> > somewhere in the config, there should be an options statement with an
> > allow transfer clause....
> >
> > Sample from Linux named.conf file:
> >
> > acl "insides4"	{ 127.0.0.1; 192.168.173.0/28; 192.168.173.32/28;
> > 192.168.173.64/28; 192.168.174.0/28; };
> > acl "insides6"	{ ::1; 2001:470:e0be::/48; 2001:470:8:4a3::/64; };
> >
> > options {
> > 	listen-on port 53 { "all4"; };
> > 	listen-on-v6 port 53 { "inside6"; "dmz6"; "loop6"; };
> >
> >            directory "/var/named";
> >            dump-file "/var/named/data/cache_dump.db";
> >            statistics-file "/var/named/data/named_stats.txt";
> >            allow-query { any; };
> > 	allow-transfer { "insides4"; "insides6"; };
> > 	allow-update { none; };
> > };
> >
> > That allow transfer says that only ip addresses in the in ACLs named
> > insides4 and insides6 are permitted to request a transfer from the
> > server. Transfers should only be permitted from master to slave DNS servers.
> >
> > Since the IBM i version is supposed to be bind 9, it should have a way
> > of putting this in or you may want to try locating the configuration
> > files and adding the allow-transfer clause and ACLs yourself.
> >
> > also... to test, you can use dig (also in IBM i now-a-days), but from
> > Linux it's:
> >
> > dig @<dns-server-ip>   AXFR
> >
> > You should not get a response when the dig is executed from any machine
> > not in the allow-transfer list.
> >
> > HTH...
> >
> >
> >
> > On 02/16/2011 02:55 PM, rob@xxxxxxxxx wrote:
> > > We've contracted with IBM to perform some threat analysis of our network.
> > > We get these qualsys reports of our vulnerabilities.
> > > One vulnerability is that an address used by a domino based quickr server
> > > exposes to some DNS Zone Transfer threat.  This machine is our DMZ.  The
> > > DNS in that DMZ is on the i and is managed with System i Navigator or
> > > iNav.  I suspect it has something to do with:
> > > netstat *cnn
> > > F15=Subset, select only that Domino address
> > > Remote           Remote  Local
> > > Address           Port    Port  Idle Time  State
> > > *                     *     53  014:44:09  Listen
> > > *                     *     53  014:44:46  *UDP
> > > 8=Display jobs
> > > Name           User
> > > QTOBDNS        QTCP
> > >
> > > What should I do about this?
> > >
> > > Here's the details of the threat:
> > > Level 3 DNS Zone Transfer port 53/tcp
> > > QID: 15018
> > > Category: DNS and BIND
> > > CVE ID: CVE-1999-0532
> > > Vendor Reference: -
> > > Bugtraq ID: -
> > > Service Modified: 06/11/2009
> > > User Modified: -
> > > Edited: No
> > > THREAT:
> > > The DNS server is a hierarchical database used to translate host names
> > > into IP addresses and IP addresses into host names. A domain is usually
> > > handled by a single DNS server. However, several servers can be installed
> > > for the purposes of load balancing or as backups.
> > > Where several servers are in use, one is called the "master" (or the
> > > primary server) and the others are called "slaves" (or secondary servers).
> > > The
> > > zone transfer feature is used to synchronize the domain (also called a
> > > zone) from the master server to the slaves. A zone transfer can be
> > > achieved
> > > by sending a single request to the name server. All information on the
> > > requested domain is then transferred, including host names, IP addresses,
> > > mail servers, etc.
> > > IMPACT:
> > > When implementing an attack, unauthorized users usually start by obtaining
> > > a company's domain name. Then, they try to gather a large number of
> > > IP addresses or host names. The more domain IP addresses they have, the
> > > better chance they have of compromising a host in your domain.
> > > SOLUTION:
> > > The Zone transfer feature should be restricted so that DNS servers can
> > > only perform a zone transfer with other DNS servers in the same domain.
> > > If you use a single DNS server, simply disable zone transfer to prevent
> > > unauthorized users from exploiting this feature from a remote system.
> > > Microsoft DNS Service users should consult their manuals. BIND users
> > > should consult the Internet Software Consortium's Web site
> > > (http://www.isc.org/).
> > > COMPLIANCE:
> > > Not Applicable
> > > EXPLOITABILITY:
> > > Metasploit
> > > Reference: CVE-1999-0532
> > > Description: DNS Enumeration Module - Metasploit Ref :
> > > /modules/auxiliary/gather/dns_enum
> > > Link: http://www.metasploit.com/modules/auxiliary/gather/dns_enum
> > > ASSOCIATED MALWARE:
> > > There is no malware information for this vulnerability.
> > > RESULTS:
> > > Name Class Type Value
> > > 180.87.208.in-addr.arpa IN SOA ns1.dekko.com postmaster.NS1.dekko.com (19
> > > 10800 3600 604800 86400)
> > > 180.87.208.in-addr.arpa IN NS ns1.dekko.com
> > > 180.87.208.in-addr.arpa IN NS ns2.mydyndns.org
> > > 26.180.87.208.in-addr.arpa IN PTR gdweb2.dekko.com
> > > 27.180.87.208.in-addr.arpa IN PTR internotes02.dekko.com
> > > 30.180.87.208.in-addr.arpa IN PTR gdsmpe01.dekko.com
> > > 31.180.87.208.in-addr.arpa IN PTR gdsmweb01.dekko.com
> > > 41.180.87.208.in-addr.arpa IN PTR xqp02.dekko.com
> > > 51.180.87.208.in-addr.arpa IN PTR www.dekkocustomers.com
> > > 52.180.87.208.in-addr.arpa IN PTR www.dekkosuppliers.com
> > > 59.180.87.208.in-addr.arpa IN PTR kdvl-ids-b108-01.dekko.com
> > > 6.180.87.208.in-addr.arpa IN PTR mail.dekko.com
> > > 65.180.87.208.in-addr.arpa IN PTR gdweb3.dekko.com
> > > 7.180.87.208.in-addr.arpa IN PTR internotes3.dekko.com
> > >
> > > Rob Berendt