Re: [dns-operations] Stunning security discovery: AXFR may leak information
Oh haven't search lists become so much fun... On Wed, 15 Apr 2015, Mark Andrews wrote: When rsh was all in fashion [...] I love that historical moment! :-) [...] Any zones you have in your search lists should be servers locally so that you can survive network partitions. These may or may not all be zones you own. With DNSSEC this includes all the parent zones unless you want to have to install and manage trust anchors for all the local zones on all machines performing validation. Good point, and subtle. Probably missed by a lot of people... the implications, regardless of if they're going to do it or not. -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Stunning security discovery: AXFR may leak information
https://www.us-cert.gov/ncas/alerts/TA15-103A http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 11:28:17AM +, Edward Lewis edward.le...@icann.org wrote a message of 126 lines which said: Newsflash: Water can make you wet. You can also notice that the US CERT, to explain how AXFR works, links to djb and not to RFC 5936... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On 4/14/15, 8:29, Mark Jeftovic mar...@easydns.com wrote: Joke all you want. This is worse than heartbleed. In short and if I understand this correctly, the problem isn't AXFR's existence or use, the problem is that systems are poorly configured. It's like blaming your aorta if a cut causes blood to spill. The problem isn't that there is an aorta, it's the cut. I understand this as a problem. Tools in common use that do not ease management or fail to make it apparent what the user has configured is worthy of CERT advisories (akin to smoking will kill you stickers I've seen on cigarette boxes). But blaming a structural element of the protocol isn't the way to address the issue. smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
https://www.us-cert.gov/ncas/alerts/TA15-103A Seems they could have mentioned NSEC as well. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
I think I should write for The Daily Currant. Paul Wouters wrote: On Tue, 14 Apr 2015, Mark Jeftovic wrote: Joke all you want. This is worse than heartbleed. Well, no. heartbleed could leak private (key) data. AXFR only leaks that which you are already willing to give to any stranger who knows what question to ask or who asks 6 billion questions :P Paul -- Mark E. Jeftovic mar...@easydns.com Founder CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 10:26:01AM -0700, Mark Boolootian wrote: https://www.us-cert.gov/ncas/alerts/TA15-103A Seems they could have mentioned NSEC as well. And NSEC3, which does help anyhow in any real sense. Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 10:23:26AM +0200, Stephane Bortzmeyer wrote: https://www.us-cert.gov/ncas/alerts/TA15-103A http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ this latest wave started on golem.de http://www.golem.de/news/dns-axfr-nameserver-verraten-geheim-urls-1504-113278.html and Heise around, well, April, 1st. While repeatedly gathering data about the prevalence and maintaining awareness can be considered a good thing, the level of substance in advisories and articles is likely to raise concerns. Without any details regarding the number of servers affected (as opposed to number of domains) and the reasons behind it - deliberation, negligence, defaults - as well as the structure of those domains(*) I fail to see why an alert level might have been reached. I'd also expect split DNS in whatever exact nomenclature to appear on the mitigation path. (*) Millions of zones out there provide little more than MX, A, and - hopefully - for www and the apex. -Peter ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
What year is this? 1986? Its a shame, cos over-reporting renders an alerts system useless. The boy who cried wolf. On 14/04/15 09:23, Stephane Bortzmeyer wrote: https://www.us-cert.gov/ncas/alerts/TA15-103A http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On 04/14/2015 04:48 PM, Mike Hoskins (michoski) wrote: Yeah, when I read the AXFR announce my first thought was wow, CERT must be bored! Seemed like old news. That said, open resolvers and BCP38 should also be old news...but a lot of people don't get it or don't care. Perhaps it was meant as more of a community broadcast to raise awareness of something DNS geeks take for common knowledge. Otherwise, would have been better sent on April 1st. some DNS geeks even enable open AXFR on purpose, btw. Open AXFR is not necessarily a security hole or data leak. Of course perhaps it may feel that way for people that think they can hide stuff by not telling people what (not) to ask. Jelte ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, 14 Apr 2015, Mark Jeftovic wrote: Joke all you want. This is worse than heartbleed. Well, no. heartbleed could leak private (key) data. AXFR only leaks that which you are already willing to give to any stranger who knows what question to ask or who asks 6 billion questions :P Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
I'm not sure this discovery should be dated 2015 http://bugs.cacert.org/view.php?id=803 http://security.stackexchange.com/questions/10452/dns-zone-transfer-attack http://www.iodigitalsec.com/dns-zone-transfer-axfr-vulnerability/ http://seclists.org/pen-test/2004/Feb/108 Stephane Bortzmeyer wrote: https://www.us-cert.gov/ncas/alerts/TA15-103A http://haxpo. nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ http: //haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ nbsp; ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 03:59:10PM +0100, Simon Munton simon.mun...@cdns.net wrote a message of 19 lines which said: What year is this? 1986? Its a shame, cos over-reporting renders an alerts system useless. Ignorance from the US CERT, plus teasing from fame-deprived security researchers. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 08:47:04PM +0200, Marjorie wrote: So the prevalence of AXFR-enabled DNS servers is still quite high. I would guess this is the result of using default configuration settings from older Bind versions What do you mean older? The 9.10 BIND ARM says this: allow-transfer Specifies which hosts are allowed to receive zone transfers from the server. allow- transfer may also be specified in the zone statement, in which case it overrides the options allow- transfer statement. If not specified, the default is to allow transfers to all hosts. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
-Original Message- From: Marjorie marjo...@id3.net Date: Tuesday, April 14, 2015 at 2:47 PM To: Samson Oduor samson.od...@accesskenya.com, Jelte Jansen jelte.jan...@sidn.nl Cc: Paul Wouters p...@nohats.ca, dns-operati...@dns-oarc.net dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Stunning security discovery: AXFR may leakinformation This is an interesting discussion actually. It's all about a rather benign but widespread misconfiguration. Not long ago, I ran a survey against a small ccTLD and tested each domain name for AXFR. The ccTLD zone file itself having been obtained - you guessed it - by way of zone transfer... Surprisingly, AXFR requests were honored by one server out of seven or something. So the prevalence of AXFR-enabled DNS servers is still quite high. I would guess this is the result of using default configuration settings from older Bind versions, but I didn't fingerprint the DNS software versions. Still many seem to consider that zone transfer is a moot point anyway, because the zone file can be reconstructed by scanning known IP ranges, then resolving hostnames. I disagree with this. There is no valid reason for exposing your network topology to the outside world. You are only making the job easier for potential attackers. Yes agreed. The finding is nothing new, and it's not a weakness in AXFR itself as others have rightly pointed out...so the timing and way in which it was reported were less than ideal...but your point is spot on. Many speak against security by obscurity but I think that is often taken too far -- in some ways blocking AXFR is no different than DMZs and firewalls...hey, why not have everything on public IP with all ports exposed? Security is an onion, and as many layers as you can put between you and the adversary are generally good assuming the obscurity is not adding unnecessary complexity or other hidden cost (proper config of a DNS server is quite easy and can be automated). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On 4/14/15, 14:47, Marjorie marjo...@id3.net wrote: The bottom line is that unrestricted AXFR is generally evil, I'd go with generally unwise. There are folks that believe it is fine to allow access to their zones and I have no reason to say they are foolish. Folks who are not concerned with the minutia of operating their DNS server most likely would not want to allow the access and the tools they use should meet their likely expectations. smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
This is an interesting discussion actually. It's all about a rather benign but widespread misconfiguration. Not long ago, I ran a survey against a small ccTLD and tested each domain name for AXFR. The ccTLD zone file itself having been obtained - you guessed it - by way of zone transfer... Surprisingly, AXFR requests were honored by one server out of seven or something. So the prevalence of AXFR-enabled DNS servers is still quite high. I would guess this is the result of using default configuration settings from older Bind versions, but I didn't fingerprint the DNS software versions. Still many seem to consider that zone transfer is a moot point anyway, because the zone file can be reconstructed by scanning known IP ranges, then resolving hostnames. I disagree with this. There is no valid reason for exposing your network topology to the outside world. You are only making the job easier for potential attackers. I think the biggest issue with zone transfers, is that they may leak information that cannot be easily guessed otherwise. Specifically: hostnames declared outside the IP ranges that are known to the attacker. For example, company acme.com may have a zone file like this (IP addresses are of course made up): IN SOA ns1.acme.com. hostmaster.acme.com. ( 2015041001 ; serial 3H ; refresh 15 ; retry 1w ; expire 3h ; minimum ) ... sqlserverA204.63.177.1 mailserverA204.63.177.21 mailserver2A204.63.177.22 sharepointA204.63.177.40 archiveA204.63.177.55 backupserverA89.52.67.31 ... By looking at the zone file, you now know they have a backup server (89.52.67.31) hosted with a third party provider, thus you have one additional target to try. Thank you AXFR for helping hackers. Occasionally I have found sensitive comments in TXT records (HINFO records are telling too, sometimes). The bottom line is that unrestricted AXFR is generally evil, except for researchers of course.AXFR is also nice when you operate a search engine and want to find as many hosts as possible. DNS is like webhosting: the majority of the users do not have in-depth understanding of the mechanisms at work. They just have enough knowledge to make things run more or less smoothly. Marj On 14-04-2015 17:52, Samson Oduor wrote: On 4/14/2015 6:38 PM, Jelte Jansen wrote: some DNS geeks even enable open AXFR on purpose, btw. Open AXFR is not necessarily a security hole or data leak. open AXFR = good for conducting reconnaissance ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
In message d152de14.add3%edward.le...@icann.org, Edward Lewis writes: On 4/14/15, 14:47, Marjorie marjo...@id3.net wrote: The bottom line is that unrestricted AXFR is generally evil, I'd go with generally unwise. There are folks that believe it is fine to allow access to their zones and I have no reason to say they are foolish. Folks who are not concerned with the minutia of operating their DNS server most likely would not want to allow the access and the tools they use should meet their likely expectations. For in-addr.arpa and ip6.arpa zones it is pointless to prevent zone transfers if you can query the zones. There is too much structure to the zones to prevent them being walked. If you have in-addr.arpa and ip6.arpa zones it is mostly pointless to block access to the corresponding forward zones as the in-addr.arpa and ip6.arpa zones give away all the names. With split horizion, you can usually guess the contents of the public zones anyway. Blocking axfr doesn't prevent tcp sockets being used. Basically all blocking axfr does is give you a false sense of security for typical zones. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
to me this harkens back to one of my earliest hacks to BIND4, which was to add an access list for TCP. of course in 1988 or whenever this was, i didn't realize that AXFR wasn't the only use of TCP, so i quickly had to patch BIND4 differently (ACL on zone transfers). fun times. the other thing i didn't realize at that time was the obvious need for an IETF BCP or FYI document saying that name servers should restrict zone transfers to nobody by default, and to provide an ACL to allow known good secondary servers to access them. had i written that RFC in 1988-ish, it might be common practice by now. (and that would have been a good time to say what RFC 5358 later said, too.) when i say that the internet is, and has always been, too open for the good of its users, i don't mean i want censorship. rather, i want admission control and access control to be the default -- all communities gated. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On 4/14/15 12:00 PM, Mike Hoskins (michoski) wrote: I disagree with this. There is no valid reason for exposing your network topology to the outside world. You are only making the job easier for potential attackers. Yes agreed. The finding is nothing new, and it's not a weakness in AXFR itself as others have rightly pointed out...so the timing and way in which it was reported were less than ideal...but your point is spot on. Many speak against security by obscurity but I think that is often taken too far -- in some ways blocking AXFR is no different than DMZs and firewalls...hey, why not have everything on public IP with all ports exposed? Security is an onion, and as many layers as you can put between you and the adversary are generally good assuming the obscurity is not adding unnecessary complexity or other hidden cost (proper config of a DNS server is quite easy and can be automated). The problem I have with the way that this is posed by the US-CERT advisory is that it neglects to point out that DNS is designed to be a public database. If you put information in the DNS that makes it easy to guess things about your network that you don't want people to guess, well, you have a problem then. Relying on AXFR restrictions to mask that problem is, at best, a weak control. (See Paul's post.) Because security is indeed an onion, AXFR restrictions really shouldn't be *that* important--just another layer in a set of good security practices. The real reason I see for restricting AXFR is to preserve resources on the server. This is less of an issue now than it was in the BIND 4 days (didn't BIND 4 used to fork() for outbound zone transfers?), but I still don't want any- and every-one to hammer my DNS servers with AXFR requests. I am kind of surprised and disappointed that the US-CERT doesn't mention that component of the issue. michael ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 2:47 PM, Marjorie marjo...@id3.net wrote: This is an interesting discussion actually. It's all about a rather benign but widespread misconfiguration. It's only a misconfiguration if the operator didn't choose to do that intentionally... Not long ago, I ran a survey against a small ccTLD and tested each domain name for AXFR. The ccTLD zone file itself having been obtained - you guessed it - by way of zone transfer... A number of ccTLD operators intentionally allow AXFR of the zone. They take the view that what is registered is: A: public and or B: will become public anyway. By allowing AXFR they cut down on dictionally attacks and similar... Surprisingly, AXFR requests were honored by one server out of seven or something. So the prevalence of AXFR-enabled DNS servers is still quite high. I would guess this is the result of using default configuration settings from older Bind versions, but I didn't fingerprint the DNS software versions. Still many seem to consider that zone transfer is a moot point anyway, because the zone file can be reconstructed by scanning known IP ranges, then resolving hostnames. I disagree with this. There is no valid reason for exposing your network topology to the outside world. You are only making the job easier for potential attackers. If your security is somehow predicated on attackers not knowing the names of machines you are going to have a bad day... I think the biggest issue with zone transfers, is that they may leak information that cannot be easily guessed otherwise. Specifically: hostnames declared outside the IP ranges that are known to the attacker. For example, company acme.com may have a zone file like this (IP addresses are of course made up): IN SOA ns1.acme.com. hostmaster.acme.com. ( 2015041001 ; serial 3H ; refresh 15 ; retry 1w ; expire 3h ; minimum ) ... sqlserverA204.63.177.1 mailserverA204.63.177.21 mailserver2A204.63.177.22 sharepointA204.63.177.40 archiveA204.63.177.55 backupserverA89.52.67.31 ... By looking at the zone file, you now know they have a backup server (89.52.67.31) hosted with a third party provider, thus you have one additional target to try. Thank you AXFR for helping hackers. Again, if you were hoping that a hacker wouldn't have thought to query for backupserver.acme.com and that this was providing you protection you will become sad. Also, let me introduce you to Farsight Security's DNSDB (https://www.dnsdb.info/#Home) (many similar, but inferior services do similar things)... Occasionally I have found sensitive comments in TXT records (HINFO records are telling too, sometimes). The bottom line is that unrestricted AXFR is generally evil, except for researchers of course. ... and those who want to cut down on dictionary attacks... and those who run public zones, like the root and .arpa, and... AXFR is also nice when you operate a search engine and want to find as many hosts as possible. This is usually not open AXFR, but rather an agreement between the search engine and TLD operators, with the TLD operator allowing AXFR from a specific source block DNS is like webhosting: the majority of the users do not have in-depth understanding of the mechanisms at work. They just have enough knowledge to make things run more or less smoothly. Marj On 14-04-2015 17:52, Samson Oduor wrote: On 4/14/2015 6:38 PM, Jelte Jansen wrote: some DNS geeks even enable open AXFR on purpose, btw. Open AXFR is not necessarily a security hole or data leak. open AXFR = good for conducting reconnaissance ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 08:29:47AM -0400, Mark Jeftovic wrote: Joke all you want. This is worse than heartbleed. Nobody can protect every DNS operator in the world from Dunning-Kruger effect and its consequences. Should we have people take an IQ test and put up a sign saying You must be *THIS* smart to run a nameserver.? Or pass a test on how to configure the nameserver of their choice? Somehow I think that isn't in the cards. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
Joke all you want. This is worse than heartbleed. Sent from my iPhone On Apr 14, 2015, at 7:28 AM, Edward Lewis edward.le...@icann.org wrote: Newsflash: Water can make you wet. Sorry. On 4/14/15, 4:23, Stephane Bortzmeyer bortzme...@nic.fr wrote: https://www.us-cert.gov/ncas/alerts/TA15-103A http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 4:31 PM, Michael Sinatra mich...@brokendns.net wrote: On 4/14/15 12:00 PM, Mike Hoskins (michoski) wrote: I disagree with this. There is no valid reason for exposing your network topology to the outside world. You are only making the job easier for potential attackers. Yes agreed. The finding is nothing new, and it's not a weakness in AXFR itself as others have rightly pointed out...so the timing and way in which it was reported were less than ideal...but your point is spot on. Many speak against security by obscurity but I think that is often taken too far -- in some ways blocking AXFR is no different than DMZs and firewalls...hey, why not have everything on public IP with all ports exposed? Security is an onion, and as many layers as you can put between you and the adversary are generally good assuming the obscurity is not adding unnecessary complexity or other hidden cost (proper config of a DNS server is quite easy and can be automated). The problem I have with the way that this is posed by the US-CERT advisory is that it neglects to point out that DNS is designed to be a public database. If you put information in the DNS that makes it easy to guess things about your network that you don't want people to guess, well, you have a problem then. Relying on AXFR restrictions to mask that problem is, at best, a weak control. (See Paul's post.) Because security is indeed an onion, AXFR restrictions really shouldn't be *that* important--just another layer in a set of good security practices. The real reason I see for restricting AXFR is to preserve resources on the server. This is less of an issue now than it was in the BIND 4 days (didn't BIND 4 used to fork() for outbound zone transfers?), but I still don't want any- and every-one to hammer my DNS servers with AXFR requests. Depends on who you are and who is interested in the contents of your zone -- if you are operating a ccTLD (and depending on the number of records, the distribution of records, phase of the moon, etc) it *may* be cheaper to simply allow AXFR instead of having a bunch of spammers do dictionary attacks trying to guess all the names. At least one ccTLD (that I know of) became much happier after they just threw in the towel and allowed AXFR... W I am kind of surprised and disappointed that the US-CERT doesn't mention that component of the issue. michael ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
-Original Message- From: Mark Andrews ma...@isc.org Date: Tuesday, April 14, 2015 at 3:57 PM To: Edward Lewis edward.le...@icann.org Cc: dns-operati...@dns-oarc.net dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Stunning security discovery: AXFR may leakinformation Basically all blocking axfr does is give you a false sense of security for typical zones. Sort of like curtains on your windows, or car alarms...yet many have those, arguably for good reason. At the very least, you probably don't want to be the only person on your block that doesn't. You should of course understand that those things alone do not provide complete security, and have the choice to use them or not. Alas, I think we are nitpicking personal preferences of knowledgeable operators (of which there could be no end) vs the advisory...the latter of which I think we all agree was kinda lame. :-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
On Tue, Apr 14, 2015 at 3:15 PM, Edward Lewis edward.le...@icann.org wrote: On 4/14/15, 14:47, Marjorie marjo...@id3.net wrote: The bottom line is that unrestricted AXFR is generally evil, I'd go with generally unwise. There are folks that believe it is fine to allow access to their zones and I have no reason to say they are foolish. +1. Included in this are (at least): . (from [b,c,f,g,k].root-servers.net) .arpa .bb .bd .bi .bv .capetown .cg .ci .cy ... and then I got bored... Some of the above operators *may* be surprised, but *certainty* not all. I know a number of the operators of the above and know that they have done this by choice. Folks who are not concerned with the minutia of operating their DNS server most likely would not want to allow the access and the tools they use should meet their likely expectations. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Stunning security discovery: AXFR may leak information
In message 152316b1-9e18-463d-b148-71cea2038...@icann.org, John L. Crain writes: Itâs important to remember that not all zones are created equal. For example the root is publicly available and the data in there by itâs nature is open accesible. The question of allowing or not allowing AXFR in such a case is more about resource usage. For L root we actually provide separate servers for those that feel a need to get the zone via AXFR, purely as a matter of resource management. At the TLD level the question of how much of the data (and non existence of data) becomes more complex and a decision has to be made about access to the zone file. As long as there is a decision made based on understanding the pros and cons of AXFR I wouldnât even go as far as to say âunwiseâ in this case. Itâs a business decision that needs to be made. Many (not all) TLDs allow access to zone files, although not always via AXFR. When it come to business networks and their DNS information I agree that âgenerally unwiseâ would be a good description. Iâm not sure what purpose allowing AXFR to the outside world meets. John When rsh was all in fashion, slaving (AXFR) the zone on the recursive servers actually made rsh safer as it prevented cache poisoning of the addresses. This was despite calls to ban it because it gave away the names. I, and I know others, have been able to debug DNS problems reported on bind-users because we could see the full zone contents which would have been harder or perhaps impossible to solve otherwise. RFC 2317 style reverse delegations really need the parent zone to be open to at a mimimum the users of the delegated address space or else reverse lookups fail when the network connection(s) to the site break. Any zones you have in your search lists should be servers locally so that you can survive network partitions. These may or may not all be zones you own. With DNSSEC this includes all the parent zones unless you want to have to install and manage trust anchors for all the local zones on all machines performing validation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
