Re: On-going Internet Emergency and Domain Names
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
Jeff Shultz <jeffshultz@wvi.com> wrote:
I won't discount the assertion that there is some sort of emergency occurring. I would however, like to see a bit of a reference to where we can learn more about what is going on (I assume this is the javascript exploit I heard about a couple days ago).
No -- it's a 0day in Internet Explorer involving animated cursors -- and it can be spread by visiting an infected web site or even by email.
Not that I like being in the position of correcting Steve :-) but the real answer is "yes" and "no" -- or ctually just yes. While the 0-day exploit is the ANI vulnerability, there are many, many compromised websites (remember the MiamiDolhins.com embedded javascript iframe redirect?) that are using similar embedded .js redirects to malware hosted sites which fancy this exploit. And some of them have vast audiences, increasing the potential for a major "issue" -- TBD. Track with the SANS ISC -- they're doing a good job of keeping the community abreast. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.0 (Build 214) wj8DBQFGDc/4q1pz9mNUZTMRAjqiAJ0UYDDep4RbSmaJ3jUdsGssSVt7AwCgnDPV PIfR8hlav9Bh20TBXBPsUZo= =wtJu -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
On Friday 30 March 2007 23:05, Fergie wrote:
-- "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
Jeff Shultz <jeffshultz@wvi.com> wrote:
I won't discount the assertion that there is some sort of emergency occurring. I would however, like to see a bit of a reference to where we can learn more about what is going on (I assume this is the javascript exploit I heard about a couple days ago).
No -- it's a 0day in Internet Explorer involving animated cursors -- and it can be spread by visiting an infected web site or even by email.
Not that I like being in the position of correcting Steve :-) but the real answer is "yes" and "no" -- or ctually just yes.
While the 0-day exploit is the ANI vulnerability, there are many, many compromised websites (remember the MiamiDolhins.com embedded javascript iframe redirect?) that are using similar embedded .js redirects to malware hosted sites which fancy this exploit.
Also to expand on that, if someone embeds this exploit or an iframe onto a high traffic site that's known to be "safe", via things like comment fields where HTML is allowed there's no telling the number of infections, it could possibly be in the hundreds of thousands of systems if an official patch isn't released - I hope Microsoft intends to release a patch by Monday at the latest.
And some of them have vast audiences, increasing the potential for a major "issue" -- TBD.
Agreed.
Track with the SANS ISC -- they're doing a good job of keeping the community abreast.
Cheers,
- ferg
whoa. this is like deja vu all over again. when barb@CERT asked me to patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host names in order to protect sendmail from a /var/spool/mqueue/qf* formatting vulnerability, i was fresh off the boat and did as i was asked. a dozen years later i find that that bug in sendmail is long gone, but the pain from BIND's "check-names" logic is still with us. i did the wrong thing and i should have said "just fix sendmail, i don't care how much easier it would be to patch libc, that's just wrong." are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make. -- Paul Vixie
On 31 Mar 2007 06:09:30 +0000, Paul Vixie <vixie@vix.com> wrote:
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
That does seem to be the single point of failure for these malwares, and for various other things besides [phish domains hosted on botnets, and registered on ccTLDs where bureaucracy comes in the way of quick takedowns] srs -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Sat, Mar 31, 2007, Suresh Ramasubramanian wrote:
On 31 Mar 2007 06:09:30 +0000, Paul Vixie <vixie@vix.com> wrote:
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
That does seem to be the single point of failure for these malwares, and for various other things besides [phish domains hosted on botnets, and registered on ccTLDs where bureaucracy comes in the way of quick takedowns]
.. just wait until they start living on in P2P trackerless type setups and not bothering with temporary domains - just use whatever resolves to the end-client. You'll wish it were as easy to track as "accessing these websites or servers." (That, and the IPv6 space doesn't seem to be a saving grace either - it'll be easy to identify potential hosts to infect by infecting someone participating in P2P and moving across to other machines as you see P2P application connections to/from them.) Scary stuff. Adrian
On 3/31/07, Adrian Chadd <adrian@creative.net.au> wrote:
.. just wait until they start living on in P2P trackerless type setups and not bothering with temporary domains - just use whatever resolves to the end-client. You'll wish it were as easy to track as "accessing these websites
p2p based botnets are already there, I'm afraid.
On Sat, Mar 31, 2007, Suresh Ramasubramanian wrote:
On 3/31/07, Adrian Chadd <adrian@creative.net.au> wrote:
.. just wait until they start living on in P2P trackerless type setups and not bothering with temporary domains - just use whatever resolves to the end-client. You'll wish it were as easy to track as "accessing these websites
p2p based botnets are already there, I'm afraid.
Shiny. Know any papers which have looked at it? Adrian
On 3/31/07, Adrian Chadd <adrian@creative.net.au> wrote:
p2p based botnets are already there, I'm afraid.
Shiny. Know any papers which have looked at it?
The recent storm worm for example seems to have had at least some p2p functionality. There's a bunch of papers, ISC SANS posts etc that can be found by a quick google for p2p+botnet -- Suresh Ramasubramanian (ops.lists@gmail.com)
On 31 Mar 2007, Paul Vixie wrote:
whoa. this is like deja vu all over again. when barb@CERT asked me to patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host names in order to protect sendmail from a /var/spool/mqueue/qf* formatting vulnerability, i was fresh off the boat and did as i was asked. a dozen years later i find that that bug in sendmail is long gone, but the pain from BIND's "check-names" logic is still with us. i did the wrong thing and i should have said "just fix sendmail, i don't care how much easier it would be to patch libc, that's just wrong."
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
I don't know about bind, obviously your knowledge over-shadows mine. Changing bind for sendmail was likely silly but it showed some agaility we seem to not have today. If it could have been a temporary dynamic solution (rather than a package change), it's an interesting concept. Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind. As to blacklisting, it's not my favorite solution but rather a limited alternative I also saw you mention on occasion. What alternatives do you offer which we can use today? Gadi.
-- Paul Vixie
On Sat, 31 Mar 2007, Gadi Evron wrote:
In this case, we speak of a problem with DNS, not sendmail, and not bind.
The argument can be made that you're trying to solve a windows-problem by implementing blocking in DNS. Next step would be to ask all access providers to block outgoing UDP/53 so people can't use open resolvers or machines set up to act as resolvers for certain DNS information that the botnets need, as per the same analysis that blocking TCP/25 stops spam. So what you're trying to do is a pure stop-gap measure that won't scale in the long run. Fix the real problem instead of trying to bandaid the symptoms. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Sat, 31 Mar 2007, Mikael Abrahamsson wrote:
On Sat, 31 Mar 2007, Gadi Evron wrote:
In this case, we speak of a problem with DNS, not sendmail, and not bind.
The argument can be made that you're trying to solve a windows-problem by implementing blocking in DNS.
Next step would be to ask all access providers to block outgoing UDP/53 so people can't use open resolvers or machines set up to act as resolvers for certain DNS information that the botnets need, as per the same analysis that blocking TCP/25 stops spam.
So what you're trying to do is a pure stop-gap measure that won't scale in the long run. Fix the real problem instead of trying to bandaid the symptoms.
The real problem? Okay, I'd like your ideas than. :) What we are referring to here is not just malware, phishing, DDoS (rings a bell, root servers?) and othr threats. It is about the DNS being manipulated and abused and causing instability across the board, only not in reachability and availability which is the infrastructure risk already being looked after. Hijacking may be resolved by DNS-SEC, this isn't. If an A record with a low TTL can be changed every 10 minutes, that means no matter what the problem is, we can't mitigate it. There are legitimate reasons to do that, though. The C&C for a botnet would not disapear, as it would be half way across the world by the time we see it. The only constant is the malicious domain name. If the NS keeps skipping around, that's just plain silly. :) If we are able to take care of all the rest, and DNS becomes the one facet which can rewind the wheel, DNS is the problem. It HAS become an infrastructure for abuse, and it disturbs daily life on the Internet. We'd like solutions and we raised some ideas - we are willing to accept they are not good ones, please help us out with better ones? Or we can look at it from a different perspective: Should bad guys be able to register thousands of domains with "amazon" and "paypal" in them every day? Should there be black hat malicious registrars around? Shouldn't there be an abuse route for domain names? One problem at a time, please. Gadi.
Port 25 is bad. It has been blocked. Port 53 is bad. Some ISPs are already going to block it. How about port 80? I think port 80 should have been the first and only port to block. Let the other ports stay alive. And maby a test for port 42 would be nice. If port 42 is answered by an IEN 116 nameserver then everything is fine. If it is windows nameservice - then shot the guy. Chance is 75% that it is a bot already. If you dont shot him chance is 75% that he will get infected anyhow. Can somebody tell me how to delay this post until midnight your time? I have unlocked the "mettre en voyage" lever already and the kettle is boiling. I am shure we built staem enough :) Cheers Peter and Karin Gadi Evron wrote:
On Sat, 31 Mar 2007, Mikael Abrahamsson wrote:
On Sat, 31 Mar 2007, Gadi Evron wrote:
In this case, we speak of a problem with DNS, not sendmail, and not bind.
The argument can be made that you're trying to solve a windows-problem by implementing blocking in DNS.
Next step would be to ask all access providers to block outgoing UDP/53 so people can't use open resolvers or machines set up to act as resolvers for certain DNS information that the botnets need, as per the same analysis that blocking TCP/25 stops spam.
So what you're trying to do is a pure stop-gap measure that won't scale in the long run. Fix the real problem instead of trying to bandaid the symptoms.
The real problem? Okay, I'd like your ideas than. :)
What we are referring to here is not just malware, phishing, DDoS (rings a bell, root servers?) and othr threats. It is about the DNS being manipulated and abused and causing instability across the board, only not in reachability and availability which is the infrastructure risk already being looked after.
Hijacking may be resolved by DNS-SEC, this isn't.
If an A record with a low TTL can be changed every 10 minutes, that means no matter what the problem is, we can't mitigate it. There are legitimate reasons to do that, though.
The C&C for a botnet would not disapear, as it would be half way across the world by the time we see it. The only constant is the malicious domain name.
If the NS keeps skipping around, that's just plain silly. :)
If we are able to take care of all the rest, and DNS becomes the one facet which can rewind the wheel, DNS is the problem. It HAS become an infrastructure for abuse, and it disturbs daily life on the Internet. We'd like solutions and we raised some ideas - we are willing to accept they are not good ones, please help us out with better ones?
Or we can look at it from a different perspective: Should bad guys be able to register thousands of domains with "amazon" and "paypal" in them every day? Should there be black hat malicious registrars around? Shouldn't there be an abuse route for domain names?
One problem at a time, please.
Gadi.
-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
On Saturday 31 March 2007 07:45, Peter Dambier wrote:
Port 25 is bad. It has been blocked. Port 53 is bad. Some ISPs are already going to block it.
How about port 80?
I think port 80 should have been the first and only port to block.
Close one, the will go to another, and another -- Nowadays, you'd have to block all 65535 ports on both TCP and UDP to get anywhere, Port blocking isn't the answer -- It ONLY postpones the attacks and such. What needs to be done is the ISPs allowing botnets and malware to run rampid on their networks to be held accountable for being negligent on their network security, Service provider abuse mailboxes should be paid more heed to, and reports should be acted upon, But I will relitterate, you can block all the ports you want, they (The origins of these attacks) will just ove to the next available one.
Kradorex Xeron wrote:
What needs to be done is the ISPs allowing botnets and malware to run rampid on their networks to be held accountable for being negligent on their network security, Service provider abuse mailboxes should be paid more heed to, and reports should be acted upon,
The presupposes that people will report problems. The situation with spam shows clearly that when the problem gets big enough, people will *stop* *reporting* *incidents*. Out of a clear blue sky, one of my servers found its way into the CBL. No spam reports, none at all. (I'm the Abuse Investigator, the one who has to read all the reports -- and the spam -- directed at abuse@$DAYJOB, so I would know.)
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Peter Dambier Sent: Saturday, March 31, 2007 4:46 AM To: nanog@merit.edu Subject: Re: On-going Internet Emergency and Domain Names
Port 25 is bad. It has been blocked.
I thought that. Rather, I thought a lot more providers would actually be blocking outbound 25 except to their SMTP servers. Just brought up a new mail server for a friend; moved an old (14+ year) domain.. I was amazed at the number of connections from rr.com, comcast.net, cox.net, verizon, etc etc etc obviously not "official" mail servers. I'm actually tempted to start blocking anything that doesn't say "mail." in it somewhere.. :)
On 2 Apr 2007, at 21:21, Lasher, Donn wrote:
Rather, I thought a lot more providers would actually be blocking outbound 25 except to their SMTP servers. Just brought up a new mail server for a friend; moved an old (14+ year) domain.. I was amazed at the number of connections from rr.com, comcast.net, cox.net, verizon, etc etc etc obviously not "official" mail servers. I'm actually tempted to start blocking anything that doesn't say "mail." in it somewhere.. :)
Lots of people do use the 'came from some consumer isp dynamic range' as a reason to block mail by using RBLs which list the entire dial-up/ dynamic ranges of ISPs they know about[0], so if you wan to have a go at doing that, don't just drop any inbound mail from mtas which don't have reverse dns set to mail.something. At least, not without telling your customers that they can outsource their mail to my company ;-) [0] - e.g. http://mail-abuse.org/dul/
You cannot mandate how hard somebody must work. It doesn't work. Make it 'expensive enough' to be wrong, and *then* they will make the necessary effort to be 'right'.
Some people block mail from bad places in an attempt to hurt the bad place, i.e. in an etempt to make it expensive for them to be bad. But nowadays there are so many bad places, so much SPAM that leaks through filters, and so many missing emails, that it becomes harder and harder to hurt the bad places by blocking email. Nowadays it is normal for email to mysteriously bounce, to go missing, to get delivered days or months late. Soon Internet email will be like IRC, a quaint service for Internet enthusiasts and oldtimers, but not a useful tool for businesses or ordinary individuals. --Michael Dillon
The only practical way to handle the volume of spam email that was hitting my servers was to implement very very aggressive filtering at the server accept level (requiring valid HELO commands that match to an existing host, among other things - amazing how many servers from major sites that initiate a HELO using a non-existent hostname)... and a friend of mine who manages a whole series of servers, has taken it to the next level: he implements his spam blocking via firewall (the disadvantage is that the logging is much more sparse, and the error messages much less descriptive). The alternative is the absurdity that a local ISP has: a 14 way cluster for mail acceptance, and another 20 way cluster for mail storage and retrieval with terabytes of storage space, 90% of the resources (or more) of which are taken up accepting and storing as much spam as possible... and this is an ISP with a few thousand dial up and DSL customers, and a small datacenter with three rows of racks. ... and none of these resource usages are billed back to the customers... they're just overhead. The current situation with email is flat out insane. There is no other way to describe it. Email quaint? You betcha - my kids and their friends do "email" all the time: via MySpace and the equivalents, no SMTP required. They wouldn't know what an email client was if you hit them over the head with it. Thomas michael.dillon@bt.com wrote:
You cannot mandate how hard somebody must work. It doesn't work. Make
it
'expensive enough' to be wrong, and *then* they will make the
necessary effort
to be 'right'.
Some people block mail from bad places in an attempt to hurt the bad place, i.e. in an etempt to make it expensive for them to be bad. But nowadays there are so many bad places, so much SPAM that leaks through filters, and so many missing emails, that it becomes harder and harder to hurt the bad places by blocking email. Nowadays it is normal for email to mysteriously bounce, to go missing, to get delivered days or months late. Soon Internet email will be like IRC, a quaint service for Internet enthusiasts and oldtimers, but not a useful tool for businesses or ordinary individuals.
--Michael Dillon
The alternative is the absurdity that a local ISP has: a 14 way cluster for mail acceptance, and another 20 way cluster for mail storage and retrieval with terabytes of storage space, 90% of the resources (or more) of which are taken up accepting and storing as much spam as possible... and this is an ISP with a few thousand dial up and DSL customers, and a small datacenter with three rows of racks. ... and none of these resource usages are billed back to the customers... they're just overhead.
Does the local ISP do any connection management? A 14 machine cluster for a few thousand users sounds on the high side. For example, we have an ISP customer with 20,000 accounts and just 3 edge servers. For those who are interested, I did a talk at the MIT Spam Conference on throttling as a way of dealing with increased spam volume. Videos are here: http://www.youtube.com/watch?v=bBwdWQfaskI http://www.youtube.com/watch?v=0pGncfRZqm0
Email quaint? You betcha - my kids and their friends do "email" all the time: via MySpace and the equivalents, no SMTP required. They wouldn't know what an email client was if you hit them over the head with it.
... And not surprisingly, the new spam frontier is being quiety fought at MySpace, SixApart, Blogger, and other social networks. There was a very interesting presentation at the MIT Spam Conference concerning blog spam at SixApart. Videos here: http://www.youtube.com/watch?v=DZjArRqSc7A http://www.youtube.com/watch?v=ODXUE66J9B0 Regards, Ken
michael.dillon@bt.com wrote:
You cannot mandate how hard somebody must work. It doesn't work. Make
it
'expensive enough' to be wrong, and *then* they will make the
necessary effort
to be 'right'.
Some people block mail from bad places in an attempt to hurt the bad place, i.e. in an etempt to make it expensive for them to be bad. But nowadays there are so many bad places, so much SPAM that leaks through filters, and so many missing emails, that it becomes harder and harder to hurt the bad places by blocking email. Nowadays it is normal for email to mysteriously bounce, to go missing, to get delivered days or months late. Soon Internet email will be like IRC, a quaint service for Internet enthusiasts and oldtimers, but not a useful tool for businesses or ordinary individuals.
--Michael Dillon
-- Ken Simpson, CEO MailChannels Corporation Reliable Email Delivery (tm) http://www.mailchannels.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 3, 2007, at 12:19 PM, Thomas Leavitt wrote:
The current situation with email is flat out insane. There is no other way to describe it.
I'd agree that the situation is bad but certainly not uncontrollable. We've had very good success keeping spam in check with a number of technologies while not really having too many problem with false positives. The last 6 months have been particularly nice. About that time we expanded our greylisting policy and that alone has made a dramatic difference. At one point before doing any greylisting we were accepting about 500,000 messages a day and delivering about 30,000. Now we accept about 80,000 and deliver about 25,000. That's a much, much more reasonable ratio. Really I don't think we are being very aggressive with our greylisting either. We currently greylist IP addresses on a handful of RBLs and ones that lack valid reverse DNS. The greylist only applies for 5 minutes and then we allow the mail through. That 5 minutes though makes all the difference in the world. We've had 2-3 senders complain (mostly about invalid reverse DNS) but really I'm fine with "fix your shit" for an answer to those people. If they can't then they can just wait the 5 minutes with all the other unwashed. Will spammers adapt? Sure. We've already seen stock spammers who are retrying at 5 minutes to the second. However, this is one of those issues where the cost of adapting may just be to high most of the time. Probably easier to just go after the weaker targets. My other theory on this is that if spammers really do adapt to greylisting, then they will have no choice but to actually start caring about bounces and clean their mailing lists. If they don't then they just won't be able to keep up with all the queued mail. Getting them to clean up their lists in itself would be a more than minor victory. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGEpLRElUlCLUT2d0RAtDVAKCilqRm5LlGOu0z19Z+5PyWLA2QSgCfas+A bCbab8uLdYtPG9XT7FgbPBM= =U9Nw -----END PGP SIGNATURE-----
I think there is definitely an adaptive factor... initially, vast quantities of spam disappeared (we have greylisting in as well), and my personal mailbox went from 100:1 spam to legit to 1:3 spam to legit... but over time, it has moved up to about a 1:1 spam to legit factor (and I get about 200-250 non-spam messages a day). Of course, we also have dozens of wildcarded domains and other legacy stuff that I wouldn't set up a site with today... Thomas Chris Owen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 3, 2007, at 12:19 PM, Thomas Leavitt wrote:
The current situation with email is flat out insane. There is no other way to describe it.
I'd agree that the situation is bad but certainly not uncontrollable. We've had very good success keeping spam in check with a number of technologies while not really having too many problem with false positives. The last 6 months have been particularly nice. About that time we expanded our greylisting policy and that alone has made a dramatic difference. At one point before doing any greylisting we were accepting about 500,000 messages a day and delivering about 30,000. Now we accept about 80,000 and deliver about 25,000. That's a much, much more reasonable ratio.
Really I don't think we are being very aggressive with our greylisting either. We currently greylist IP addresses on a handful of RBLs and ones that lack valid reverse DNS. The greylist only applies for 5 minutes and then we allow the mail through. That 5 minutes though makes all the difference in the world. We've had 2-3 senders complain (mostly about invalid reverse DNS) but really I'm fine with "fix your shit" for an answer to those people. If they can't then they can just wait the 5 minutes with all the other unwashed.
Will spammers adapt? Sure. We've already seen stock spammers who are retrying at 5 minutes to the second. However, this is one of those issues where the cost of adapting may just be to high most of the time. Probably easier to just go after the weaker targets.
My other theory on this is that if spammers really do adapt to greylisting, then they will have no choice but to actually start caring about bounces and clean their mailing lists. If they don't then they just won't be able to keep up with all the queued mail. Getting them to clean up their lists in itself would be a more than minor victory.
Chris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFGEpLRElUlCLUT2d0RAtDVAKCilqRm5LlGOu0z19Z+5PyWLA2QSgCfas+A bCbab8uLdYtPG9XT7FgbPBM= =U9Nw -----END PGP SIGNATURE-----
On Sat, 2007-03-31 at 06:16 -0500, Gadi Evron wrote:
Or we can look at it from a different perspective: Should bad guys be able to register thousands of domains with "amazon" and "paypal" in them every day? Should there be black hat malicious registrars around? Shouldn't there be an abuse route for domain names?
One problem at a time, please.
Based on Lorenzen's data, domain tasting enables millions of domain names to be in flux every day. Exchange lists this large to end users is extremely costly. When small handguns became a weapon of choice for holdups, a waiting period was imposed to allow enforcement agencies time to block exchanges. Even when bad actors can be identified, a reporting lag of 12 to 24 hours in the case of global registries ensures there can be no preemptive response. If enforcement at this level is to prevent crime, registries would need to help by providing some advanced notice. Perhaps all registries should be required to report public details of domain name additions 24 hours in advance of the same details being published in the TLD zones. -Doug
What about a worldwide clearing house where all registrars must submit their domains for some basic verification? Naming: For phishing reasons. I think detection of possible trademark violations would be too contentious. Contact info: It's fine to use a proxy to hide true ownership to the public, but the clearing house would verify telephone numbers and addresses against public and private databases, and for those countries that don't have that well built-out, something that ties payment (whether that be credit card, bank transfer, or check) to a piece of identification as strong as a passport. Funding of such a clearing house: a flat fee per domain Maintenance: It can't be a one-time event, but I'm not sure how this would look. Of course, the above is only utopia and the problem has to get much worse before we'll see international cooperation. Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Douglas Otis Sent: Saturday, March 31, 2007 9:47 AM To: Gadi Evron Cc: nanog@merit.edu Subject: Re: On-going Internet Emergency and Domain Names On Sat, 2007-03-31 at 06:16 -0500, Gadi Evron wrote:
Or we can look at it from a different perspective: Should bad guys be able to register thousands of domains with "amazon" and "paypal" in them every day? Should there be black hat malicious registrars around? Shouldn't there be an abuse route for domain names?
One problem at a time, please.
Based on Lorenzen's data, domain tasting enables millions of domain names to be in flux every day. Exchange lists this large to end users is extremely costly. When small handguns became a weapon of choice for holdups, a waiting period was imposed to allow enforcement agencies time to block exchanges. Even when bad actors can be identified, a reporting lag of 12 to 24 hours in the case of global registries ensures there can be no preemptive response. If enforcement at this level is to prevent crime, registries would need to help by providing some advanced notice. Perhaps all registries should be required to report public details of domain name additions 24 hours in advance of the same details being published in the TLD zones. -Doug
On Sat, 2007-03-31 at 11:09 -0500, Frank Bulk wrote: > On Sat, 31 Mar 2007 07:46:47 -0700, Douglas Otis wrote:
Even when bad actors can be identified, a reporting lag of 12 to 24 hours in the case of global registries ensures there can be no preemptive response. If enforcement at this level is to prevent crime, registries would need to help by providing some advanced notice. Perhaps all registries should be required to report public details of domain name additions 24 hours in advance of the same details being published in the TLD zones.
What about a worldwide clearing house where all registrars must submit their domains for some basic verification?
Rather than a clearinghouse, require gTLDs, ccTLDs, and SLDs establish rules regarding access to a 24 hour preview of zone transfers. Establish some type of international domain dispute resolution agency that responds to hold requests made by recognized legal authorities. Establishing transfers for the next day's zone provides extremely valuable information that would significantly aid efforts in fighting crime. An advanced warning permits deployment of preemptive technologies. This technology could be bind10, but there are other solutions as well. Legal authorities should also be able to request holds placed on specific domains when the minimal details appear related to criminal activity, such as names commonly used for look-alike attacks. Only then would additional information become relevant, and be handled by the domain dispute resolution agency. They would not be a general clearinghouse.
Naming: For phishing reasons. I think detection of possible trademark violations would be too contentious.
Agreed.
Contact info: It's fine to use a proxy to hide true ownership to the public, but the clearing house would verify telephone numbers and addresses against public and private databases, and for those countries that don't have that well built-out, something that ties payment (whether that be credit card, bank transfer, or check) to a piece of identification as strong as a passport.
While this sounds like an excellent idea, it also seems unlikely the current levels of trust permits a broad sharing of such detail in the fashion of a clearinghouse. Just a 24 hour advanced peak at tomorrow's zone file would not represent any additional data preparation, nor would this be information someone wishes to keep private. After all, there is competition between registrars.
Funding of such a clearing house: a flat fee per domain Maintenance: It can't be a one-time event, but I'm not sure how this would look.
Perhaps registries should be allowed to charge a small fee to cover just the expense related to the transfers.
Of course, the above is only utopia and the problem has to get much worse before we'll see international cooperation.
The financial damage caused by crime taking advantage of DNS features to then dance rapidly over the globe should justify rather minor changes to the current mode of registry operations. -Doug
Even when bad actors can be identified, a reporting lag of 12 to 24 hours in the case of global registries ensures there can be no preemptive response. If enforcement at this level is to prevent crime, registries would need to help by providing some advanced notice. Perhaps all registries should be required to report public details of domain name additions 24 hours in advance of the same details being published in the TLD zones.
What about a worldwide clearing house where all registrars must submit
For some operations or situations 24 hours would be too long a time to wait. There would need to be some mechanism where the delay could be bypassed. Frank -----Original Message----- From: Douglas Otis [mailto:dotis@mail-abuse.org] Sent: Saturday, March 31, 2007 4:05 PM To: frnkblk@iname.com Cc: nanog@merit.edu Subject: RE: On-going Internet Emergency and Domain Names On Sat, 2007-03-31 at 11:09 -0500, Frank Bulk wrote: > On Sat, 31 Mar 2007 07:46:47 -0700, Douglas Otis wrote: their
domains for some basic verification?
Rather than a clearinghouse, require gTLDs, ccTLDs, and SLDs establish rules regarding access to a 24 hour preview of zone transfers. Establish some type of international domain dispute resolution agency that responds to hold requests made by recognized legal authorities. Establishing transfers for the next day's zone provides extremely valuable information that would significantly aid efforts in fighting crime. An advanced warning permits deployment of preemptive technologies. This technology could be bind10, but there are other solutions as well. Legal authorities should also be able to request holds placed on specific domains when the minimal details appear related to criminal activity, such as names commonly used for look-alike attacks. Only then would additional information become relevant, and be handled by the domain dispute resolution agency. They would not be a general clearinghouse.
Naming: For phishing reasons. I think detection of possible trademark violations would be too contentious.
Contact info: It's fine to use a proxy to hide true ownership to the
Agreed. public,
but the clearing house would verify telephone numbers and addresses against public and private databases, and for those countries that don't have that well built-out, something that ties payment (whether that be credit card, bank transfer, or check) to a piece of identification as strong as a passport.
While this sounds like an excellent idea, it also seems unlikely the current levels of trust permits a broad sharing of such detail in the fashion of a clearinghouse. Just a 24 hour advanced peak at tomorrow's zone file would not represent any additional data preparation, nor would this be information someone wishes to keep private. After all, there is competition between registrars.
Funding of such a clearing house: a flat fee per domain Maintenance: It can't be a one-time event, but I'm not sure how this would look.
Perhaps registries should be allowed to charge a small fee to cover just the expense related to the transfers.
Of course, the above is only utopia and the problem has to get much worse before we'll see international cooperation.
The financial damage caused by crime taking advantage of DNS features to then dance rapidly over the globe should justify rather minor changes to the current mode of registry operations. -Doug
On Sat, 2007-03-31 at 16:47 -0500, Frank Bulk wrote:
For some operations or situations 24 hours would be too long a time to wait. There would need to be some mechanism where the delay could be bypassed.
What operation requires a new domain be published within 24 hours? Even banks require several days before honoring checks as protection against fraud. A slight delay allows preemptive enforcement measures. It seems most if not all operations could factor in this delay into their planning. -Doug
Douglas Otis wrote:
On Sat, 2007-03-31 at 16:47 -0500, Frank Bulk wrote:
For some operations or situations 24 hours would be too long a time to wait. There would need to be some mechanism where the delay could be bypassed.
What operation requires a new domain be published within 24 hours? Even banks require several days before honoring checks as protection against fraud. A slight delay allows preemptive enforcement measures. It seems most if not all operations could factor in this delay into their planning.
"Sips of knowledge intoxicates the mind, while deeper drinking sobers it again." Where did you drink that Kool-Aide? Back when I was in the bank automation business, the main effort was to build a "quick-clearing" process, measured in hours, for checks. The idea is that an electronic recording of the check would be sent to the issuing bank, payment made by the issuing bank to the account of the receiving bank, and the payment confirmed when the physical paper (or photocopy) of the check arrived. (If the paper never showed up, the issuing bank would reverse the transfer of the money.) The idea of fractional-day clearing was to reduce the float between banks. Whether that fractional-day clearing made all the way to the customer is the decision of the receiving bank, as it controls when the funds are released to the depositor. The receiving bank can *use* that money if it doesn't credit the depositing account immediately, but waits a day. I'm a customer. I want a domain name *now*, not in the future. I believe that, given the speed of the Internet, there is no reason to introduce delays. As for "tasting", I'm against it. The cost of a domain name is small enough that there is no need to have a tasting. Some of the excuses I've seen to support tasting can readily be handled by other processes that have the same effect, but without the potential for harm by abusers.
On Sat, 31 Mar 2007, Douglas Otis wrote:
Rather than a clearinghouse, require gTLDs, ccTLDs, and SLDs establish rules regarding access to a 24 hour preview of zone transfers.
You know what would be even safer? Let's go back to ftp'ing a hosts.txt file around every week or so! --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
Gadi Evron wrote:
The real problem? Okay, I'd like your ideas than. :)
Just because one doesn't have a solution to the real problem doesn't invalidate them from objecting to an idea presented by someone else, you know? Trying to "fix" DNS this way is just the wrong thing to do, even though the goal is honorable. We'll just end up having them do something else instead and the attempts we've made will be in vain and will likely have ended up with limitations to ourselves rather than to them. They will adapt to any change like this we would try to do. The only real way to attempt to stop this is lobbying for legislation, nailing people for what we see around us and the damage they cause us and to make it risky business rather than the piece of cake it is today. Anything else is just a minor setback for them, and a HUGE deal of investment and money for "us" on top of what we already spend handling what we're exposed to. -- /ahnberg.
Mattias Ahnberg wrote:
They will adapt to any change like this we would try to do. The only real way to attempt to stop this is lobbying for legislation, nailing people for what we see around us and the damage they cause us and to make it risky business rather than the piece of cake it is today. Anything else is just a minor setback for them, and a HUGE deal of investment and money for "us" on top of what we already spend handling what we're exposed to.
I second this motion, I think the only way to make a step change for the better is to seek and implement measures that make it more expensive and challenging to be in the badware/phishing/spam business. These measures should also hold their ground and push the problem into the backyards of those who choose to ignore the crap they allow into the public network. Unfortunately nothing to address this seriously exists today and I've yet to identify serious effort to get this done. I'd be happy to be part of such endeavour if one is going to be founded someday. But I do believe it could be done. Even without "clean slate" daydreaming. Pete
On Sat, 31 Mar 2007, Mattias Ahnberg wrote:
Gadi Evron wrote:
The real problem? Okay, I'd like your ideas than. :)
Just because one doesn't have a solution to the real problem doesn't invalidate them from objecting to an idea presented by someone else, you know?
Trying to "fix" DNS this way is just the wrong thing to do, even though the goal is honorable. We'll just end up having them do something else instead and the attempts we've made will be in vain and will likely have ended up with limitations to ourselves rather than to them.
They will adapt to any change like this we would try to do. The only real way to attempt to stop this is lobbying for legislation, nailing people for what we see around us and the damage they cause us and to make it risky business rather than the piece of cake it is today. Anything else is just a minor setback for them, and a HUGE deal of investment and money for "us" on top of what we already spend handling what we're exposed to.
Amen. Really. I'd honestly like more ideas.
-- /ahnberg.
On Sat, 31 Mar 2007, Stephen Satchell wrote:
Gadi Evron wrote:
Amen. Really.
I'd honestly like more ideas.
What did IETF and ICANN say when you approached them through their public-comment channels?
ICANN is well aware of the issues through their visibility into operational groups, and I am far from an expert on public policy (which is why I mentioned we are studyign that option). ICANN has not shown any interest or ability to affect change in this realm. ICANN's work is elsewhere. People at ICANN understand though, and I have no personal issue with any of them. IETF? I never tried to contact them. Maybe others did, maybe not. If you can help with any of these (if you believe they will affect change in the operational realm), we would appreciate it.
On Sat, Mar 31, 2007, Gadi Evron wrote:
On Sat, 31 Mar 2007, Stephen Satchell wrote:
Gadi Evron wrote:
Amen. Really.
I'd honestly like more ideas.
What did IETF and ICANN say when you approached them through their public-comment channels?
ICANN is well aware of the issues through their visibility into operational groups, and I am far from an expert on public policy (which is why I mentioned we are studyign that option). ICANN has not shown any interest or ability to affect change in this realm. ICANN's work is elsewhere.
People at ICANN understand though, and I have no personal issue with any of them.
IETF? I never tried to contact them. Maybe others did, maybe not.
If you can help with any of these (if you believe they will affect change in the operational realm), we would appreciate it.
I hazard a guess and say they'll probably say similar things to the general response on this mailing list - DNS is one of many possible attack vectors and is most probably the wrong spot to do this. Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is. I view this kind of thing as an operational issue insomuch as it might affect my network - but malware writers are botnet operators are smarter than they once were and aren't nearly as "spray your mark everywhere as quickly as possible" as exploits used to be. Adrian
On Sun, 1 Apr 2007, Adrian Chadd wrote:
Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is.
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
I view this kind of thing as an operational issue insomuch as it might affect my network - but malware writers are botnet operators are smarter than they once were and aren't nearly as "spray your mark everywhere as quickly as possible" as exploits used to be.
As to malware: Protect against malware on your network, this isn't what this is about. It's about your network's security being reliant on someone half way across the world taking care of it. Gadi.
Adrian
On Sat, Mar 31, 2007, Gadi Evron wrote:
On Sun, 1 Apr 2007, Adrian Chadd wrote:
Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is.
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
And as I said tongue in cheek before - so is IP. Where do you draw the line?
I view this kind of thing as an operational issue insomuch as it might affect my network - but malware writers are botnet operators are smarter than they once were and aren't nearly as "spray your mark everywhere as quickly as possible" as exploits used to be.
As to malware: Protect against malware on your network, this isn't what this is about. It's about your network's security being reliant on someone half way across the world taking care of it.
For the few I'm currently responsible for; you can be absolutely certain my network security is reliant on me, not someone else. I'm trying to push out the "You've got to be responsible for what you send just as much as what you receive" out to clients who only seem to take notice after their first spam blacklisting, or sneaky malware infection. Have you tried pursuing the root cause of all of this horribleness - badly written software? Adrian
On Sunday 01 April 2007 00:35, Adrian Chadd wrote:
On Sat, Mar 31, 2007, Gadi Evron wrote:
On Sun, 1 Apr 2007, Adrian Chadd wrote:
Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is.
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
And as I said tongue in cheek before - so is IP. Where do you draw the line?
Agreed, Really, with this block this, block that, block the other additude so many people have nowadays, soon enough, unless we make the effort to stop the problems
I view this kind of thing as an operational issue insomuch as it might affect my network - but malware writers are botnet operators are smarter than they once were and aren't nearly as "spray your mark everywhere as quickly as possible" as exploits used to be.
As to malware: Protect against malware on your network, this isn't what this is about. It's about your network's security being reliant on someone half way across the world taking care of it.
For the few I'm currently responsible for; you can be absolutely certain my network security is reliant on me, not someone else.
I applaud you for your efforts, as well as to anyone else's on this list who makes efforts.
I'm trying to push out the "You've got to be responsible for what you send just as much as what you receive" out to clients who only seem to take notice after their first spam blacklisting, or sneaky malware infection.
Indeed, end users see their computer infected with something and they act innocent whenever something goes wrong with it, Users often times REFUSE to take responsibility if their computer becomes a problem. Users simply don't see the importance of keeping their computer secured.
Have you tried pursuing the root cause of all of this horribleness - badly written software?
Good point, Software companies that create badly written code then put it out on the market should be more-so held accountable, Until these companies are held FULLY responsible for exploits and such, you're going to keep seeing things like "Months of bugs", it's because software companies keep rushing software out to the market to sell it, they're not concerned about security if you can make a month of bugs from one of their products, they're more concerned about the income and don't do enough security testing and QA before the software leaves their shop, and end-users will more than likely not ask about security of the software, because all they want to do is chat with their aunt bella somewhere. It's badly written software that is one of the main vectors of botners and such, we shouldn't be going after DNS
Adrian
Gadi Evron wrote:
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
Imminent death of the Internet predicted. News at 11. This fearmongering is getting to the scale of democrazy exports. Pete
On Sun, 1 Apr 2007, Petri Helenius wrote:
Gadi Evron wrote:
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
Imminent death of the Internet predicted. News at 11.
This fearmongering is getting to the scale of democrazy exports.
No fear, no uncertainty. This is not about the death of the Internet. Wake up and start reading your email elsewhere.
Pete
On Sunday 01 April 2007 01:42, you wrote:
Gadi Evron wrote:
Thing is, the problem IS in the core. DNS is no longer just being abused, it is pretty much an abuse infrastructure. That needs to be fixed if security operations on the Internet at their current effectiveness (which is low as it is) are to be maintained past Q4 2007-Q2 2008.
Imminent death of the Internet predicted. News at 11.
This fearmongering is getting to the scale of democrazy exports.
Pete
I would also like to point out as to echo one of my other posts: If we get block happy, they (The people abusing the exploits) WILL simply move to another port, andother protocol, so unless we're willing to block every port, every protcool, to ensure that it cannot become a vector, I suggest we STOP and think tactically: Will blocking these protocols stop these people? Or will they just move to exploit another port and/or protocol? Sadly, if blocking ports and protocols becomes the only method to control things like this from occurring, I sadly will have to agree with Pete's post, as soon we're going to have all 65535 ports on all protocols (TCP, UDP, etc) blocked.
Kradorex Xeron wrote:
Sadly, if blocking ports and protocols becomes the only method to control things like this from occurring, I sadly will have to agree with Pete's post, as soon we're going to have all 65535 ports on all protocols (TCP, UDP, etc) blocked.
65536 ports for UDP... Pete
ge@linuxbox.org (Gadi Evron) writes:
On Sun, 1 Apr 2007, Adrian Chadd wrote:
Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is.
Thing is, the problem IS in the core.
nope. read what he wrote-- "it won't work, honest". the problem is on the front-end, an "edge", specifically in the way domain tasting works. does anyone really believe that there will ever again be a million domains added to the DNS in a 24-hour period? (of course not.) then why do verisign and the other TLD registries have to cope with many millions of updates per day? if we solve THAT problem, which is difficult and barely tractible, then the "dns core" will go on as before, working just fine all the while.
DNS is no longer just being abused, it is pretty much an abuse infrastructure.
do you mean DNS or do you mean every Internet technology including IP, UDP, TCP, ICMP, BGP, etc; plus most non-Internet-specific technologies including ASCII, Unicode, 32-bit, 64-bit, and binary? "the internet, and technology in general, is no longer just being abused, it is pretty much an abuse infrastructure." <--- i'd agree with *that*. (but this is not the first time I've been irritated that I can't choose which other humans to share the galaxy with and which ones I'd like to kick out.) -- Paul Vixie
On 1 Apr 2007, Paul Vixie wrote:
ge@linuxbox.org (Gadi Evron) writes:
On Sun, 1 Apr 2007, Adrian Chadd wrote:
Stop trying to fix things in the core - it won't work, honest - and start trying to fix things closer to the edge where the actual problem is.
Thing is, the problem IS in the core.
nope. read what he wrote-- "it won't work, honest". the problem is on the front-end, an "edge", specifically in the way domain tasting works. does anyone really believe that there will ever again be a million domains added to the DNS in a 24-hour period? (of course not.) then why do verisign and the other TLD registries have to cope with many millions of updates per day? if we solve THAT problem, which is difficult and barely tractible, then the "dns core" will go on as before, working just fine all the while.
DNS is no longer just being abused, it is pretty much an abuse infrastructure.
do you mean DNS or do you mean every Internet technology including IP, UDP, TCP, ICMP, BGP, etc; plus most non-Internet-specific technologies including ASCII, Unicode, 32-bit, 64-bit, and binary?
"the internet, and technology in general, is no longer just being abused, it is pretty much an abuse infrastructure." <--- i'd agree with *that*. (but this is not the first time I've been irritated that I can't choose which other humans to share the galaxy with and which ones I'd like to kick out.)
I stand corrected, the Internet is obviously the problem and botnets are the very seriosu symptom, but consider: This is not a DNS server being abused, it is the infrastructure. The "network", centralized and de-centralized. So yes, DNS has become an infrastructure for abuse even if the Internet itself is not very safe. Gadi.
-- Paul Vixie
On Sun, 1 Apr 2007, David Conrad wrote:
On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote:
ICANN has not shown any interest or ability to affect change in this realm.
I'm not clear what "this realm" actually is.
Abuse and Security (non infrastructure). ICANN, as far as I understand, manages the business side of things. If I am wrong, I'd be happy to learn more. Can you share with us what your thoughts are? Gadi.
Rgds, -drc
On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:
On Sun, 1 Apr 2007, David Conrad wrote:
On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote: I'm not clear what "this realm" actually is. Abuse and Security (non infrastructure).
Well, ICANN is supposed to look after the "security and stability" of the Internet, which is sufficiently vague and ambiguous to cover pretty much anything. I was actually looking for something a bit more concrete. The one concrete suggestion I've seen is to induce a delay in zone creation and publish a list of newly created names within the zone. The problem with this is that is sort of assumes: a) the registries all work on similar timescales b) that timescale is on the order of a day c) ICANN has a mechanism to induce the registries to make changes to those timescales d) making changes along these lines would be what end users actually want. Of these options: - (a) isn't true (by observation) - (b) is currently true for com/net, but I don't expect that to last -- I've heard there is a lot of competitive pressure on the registries to be faster in doing zone modifications - (c) I don't think is true now for even those TLDs ICANN has a contractual relationship with and is highly unlikely to ever be true for the vast majority of TLDs - (d) probably isn't true, given lots of people complain about how long it takes to get zone changes done now and I believe registries are working to reduce the amount of time significantly due to customer demand. Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this? Rgds, -drc P.S. I should point out that IANA has only glancing interaction with the registry/registrar world, so I'm working from a large amount of ignorance here. Fortunately, being ignorant rarely stops me... :-)
On Mon, 2 Apr 2007, David Conrad wrote:
On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:
On Sun, 1 Apr 2007, David Conrad wrote:
On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote: I'm not clear what "this realm" actually is. Abuse and Security (non infrastructure).
Well, ICANN is supposed to look after the "security and stability" of the Internet, which is sufficiently vague and ambiguous to cover pretty much anything. I was actually looking for something a bit more concrete.
So you are the guys asleep at the guard post? :)
The one concrete suggestion I've seen is to induce a delay in zone creation and publish a list of newly created names within the zone. The problem with this is that is sort of assumes:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details. 2. Following these incidents as they happen so that YOU, in charge, can make these suggestion? 3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core? 4. Black lists for providers are not perfect, but perhaps they could help protect users significantly? 5. Enforcing that registrars act in say, not a whitehat fashion, but a not blackhat fashion? 6. Yours here? I can go to extremes in my suggestions, non are new: 1. Rather than terminate on fake details - verify details before a domain is registered. Not just the credit card, either. 2. Domains are a commodity, ICANN should know, what of putting them under a wider license on abuse and termination or suspension? The whole system is almost completely unregulated, and this is money you take care of that we speak of here. You have a long way to go before claiming to take care of the Internet. Please take that route if you believe you can. The Internet needs your help. How about some funding for research projects? Getting involved and perhaps funding Incident response on a global scale? Why does this have to be in the hands of volunteers, such as myself and hundreds of others? Why does Internet security have to be in the hands of those with "good will" rather than those who are supposed to take care of it? How about adding security to the main agenda along-side with the .xxx TLD? I have no problem with ICANN, but there is a long way to go before you can claim to protect the Internet, infrastructure, users, or what's in the middle. I'd encourage ICANN to take that road, much like I would encourage any person or organization that wants to help. You were not here before when we needed you, so organizations like FIRST, the ISOTF and many good-will based groups were created. You are here now, how do we proceed? What is ICANNs next step? I will support it, so will others. It's not about politics as much as it is about who DOES. Maybe you just need to work with the community rather than claim to run it when you don't really do anything in security quite yet.
a) the registries all work on similar timescales b) that timescale is on the order of a day c) ICANN has a mechanism to induce the registries to make changes to those timescales d) making changes along these lines would be what end users actually want.
Of these options:
- (a) isn't true (by observation) - (b) is currently true for com/net, but I don't expect that to last -- I've heard there is a lot of competitive pressure on the registries to be faster in doing zone modifications - (c) I don't think is true now for even those TLDs ICANN has a contractual relationship with and is highly unlikely to ever be true for the vast majority of TLDs - (d) probably isn't true, given lots of people complain about how long it takes to get zone changes done now and I believe registries are working to reduce the amount of time significantly due to customer demand.
Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
Well, if a domain was registered last month, last week, or 2 hours ago, and is used to send spam, host a phishing site or changes name servers that support phishing sites ALONE (nothing legit) in the thousands, or support the sending of billions of email messages burdening messaging across the board, I'd call it bad. Who "one" is, now that is something to work out. We need help setting the system in place with guidelines and policies so that the one or other can start reporting and getting results. Is ICANN willing to help?
-drc
Gadi.
P.S. I should point out that IANA has only glancing interaction with the registry/registrar world, so I'm working from a large amount of ignorance here. Fortunately, being ignorant rarely stops me... :-)
On Apr 2, 2007, at 7:02 PM, Gadi Evron wrote:
On Mon, 2 Apr 2007, David Conrad wrote:
On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:
The one concrete suggestion I've seen is to induce a delay in zone creation and publish a list of newly created names within the zone. The problem with this is that is sort of assumes:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
This requires a separate agency tasked to respond to reports of crime. Registrars have a conflict of interest (they want to be profitable). Even answering the phone to deal with this type of problem costs more than a registration is worth. Hence, it is easier to establish domain tasting which essentially drops this entire problem into someone else's lap.
2. Following these incidents as they happen so that YOU, in charge, can make these suggestion?
Often enforcement policies begins with a complaint. But who is taking the role of enforcement?
3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core?
It would be nice if there were an agency that had a mechanism in place for routinely yanking domains that pose a public threat. Who would you trust in that role? Unfortunately, the US has lost their credibility as loudly echoed on this list.
4. Black lists for providers are not perfect, but perhaps they could help protect users significantly?
Black-hole or block-lists is where protection can be introduced, political push back will thwart centralized enforcement. To support this mode of operation, a preview mode of operation would be highly beneficial. Currently bad actors will keep such efforts in a futile feckless reactive mode.
5. Enforcing that registrars act in say, not a whitehat fashion, but a not blackhat fashion?
Of course a bad registrar might warrant greater scrutiny. At what point would all their customers need to find a different registrar?
6. Yours here?
Perhaps only banks should be allowed to act as registrars? At least they know how to check physical IDs. -Doug
Gadi,
So you are the guys asleep at the guard post? :)
Something ICANN is frequently accused of.
1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
Seems like a reasonable idea to me, but wouldn't that be a contractual term between the registrar and registrant?
2. Following these incidents as they happen so that YOU, in charge, can make these suggestion?
Sorry, who is in charge?
3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core?
I don't understand this one. What's "the core" in this context?
4. Black lists for providers are not perfect, but perhaps they could help protect users significantly?
Perhaps they could. Not sure what ICANN would have to do with this though (unless you're suggesting ICANN runs a blacklist? If so, I suspect ICANN's legal counsel would have ... concerns).
5. Enforcing that registrars act in say, not a whitehat fashion, but a not blackhat fashion?
Sorry, what does this mean?
6. Yours here?
Sorry, haven't really looked into this space, so I don't yet have suggestions.
1. Rather than terminate on fake details - verify details before a domain is registered. Not just the credit card, either.
Isn't this a business practice of the registrars? I gather you're suggesting ICANN take a much more aggressive role with registrars?
2. Domains are a commodity, ICANN should know, what of putting them under a wider license on abuse and termination or suspension?
My observations are that the relationship between ICANN and the registry/registrar folks is much less dictatorial than you appear to assume.
The whole system is almost completely unregulated, and this is money you take care of that we speak of here.
There are many who argue quite forcefully that ICANN is not a regulator.
You have a long way to go before claiming to take care of the Internet.
I don't think ICANN has ever claimed this.
Please take that route if you believe you can. The Internet needs your help.
You seem to believe ICANN has a much greater role in Internet management than it has. ICANN can't even make changes to a name server in the root zone without US government approval.
How about some funding for research projects? Getting involved and perhaps funding Incident response on a global scale?
I can suggest this, although having a concrete proposal would probably carry more weight.
Why does this have to be in the hands of volunteers, such as myself and hundreds of others?
Why does Internet security have to be in the hands of those with "good will" rather than those who are supposed to take care of it?
I suspect because the Internet is decentralized.
How about adding security to the main agenda along-side with the .xxx TLD?
It is, although there are lots of aspects to security so undoubtedly, it can't be all things to all people. ICANN has an advisory committee specifically targeted at "security and stability" that has some folks who frequently participate on this list (http:// www.icann.org/committees/security/).
I have no problem with ICANN, but there is a long way to go before you can claim to protect the Internet, infrastructure, users, or what's in the middle.
I don't think ICANN claims this.
I'd encourage ICANN to take that road, much like I would encourage any person or organization that wants to help.
You were not here before when we needed you, so organizations like FIRST, the ISOTF and many good-will based groups were created. You are here now, how do we proceed?
I don't think anyone expected ICANN to take on the role of Internet security czar. I suspect if ICANN tried to assert this sort of role, the USG (among other governments) would take strong exception. ICANN's role (as I understand it) is coordinative, not directive. Any attempt to go beyond this will result in ICANN getting slapped down.
What is ICANNs next step? I will support it, so will others. It's not about politics as much as it is about who DOES. Maybe you just need to work with the community rather than claim to run it when you don't really do anything in security quite yet.
I don't think ICANN has ever claimed to run "the community".
Well, if a domain was registered last month, last week, or 2 hours ago, and is used to send spam, host a phishing site or changes name servers that support phishing sites ALONE (nothing legit) in the thousands, or support the sending of billions of email messages burdening messaging across the board, I'd call it bad.
As would I.
Who "one" is, now that is something to work out. We need help setting the system in place with guidelines and policies so that the one or other can start reporting and getting results.
Is ICANN willing to help?
To be perfectly clear, I don't speak for ICANN, I just run IANA. I'm happy to forward suggestions to folks in ICANN who don't participate in NANOG or other forums, but don't expect this to have significantly more impact than you participating directly in the various ICANN forums. Rgds, -drc
[Top-Posting] Thanks David, of course, as you know, this was not an attack on you. I appreciate you clarifying to me a bitmore on what ICANN does, does not and is not supposed to do. I will contact you off-list for further consultation. Many thanks again for all your help! So, who *is* able to help affect change? Gadi. On Mon, 2 Apr 2007, David Conrad wrote:
Gadi,
So you are the guys asleep at the guard post? :)
Something ICANN is frequently accused of.
1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
Seems like a reasonable idea to me, but wouldn't that be a contractual term between the registrar and registrant?
2. Following these incidents as they happen so that YOU, in charge, can make these suggestion?
Sorry, who is in charge?
3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core?
I don't understand this one. What's "the core" in this context?
4. Black lists for providers are not perfect, but perhaps they could help protect users significantly?
Perhaps they could. Not sure what ICANN would have to do with this though (unless you're suggesting ICANN runs a blacklist? If so, I suspect ICANN's legal counsel would have ... concerns).
5. Enforcing that registrars act in say, not a whitehat fashion, but a not blackhat fashion?
Sorry, what does this mean?
6. Yours here?
Sorry, haven't really looked into this space, so I don't yet have suggestions.
1. Rather than terminate on fake details - verify details before a domain is registered. Not just the credit card, either.
Isn't this a business practice of the registrars? I gather you're suggesting ICANN take a much more aggressive role with registrars?
2. Domains are a commodity, ICANN should know, what of putting them under a wider license on abuse and termination or suspension?
My observations are that the relationship between ICANN and the registry/registrar folks is much less dictatorial than you appear to assume.
The whole system is almost completely unregulated, and this is money you take care of that we speak of here.
There are many who argue quite forcefully that ICANN is not a regulator.
You have a long way to go before claiming to take care of the Internet.
I don't think ICANN has ever claimed this.
Please take that route if you believe you can. The Internet needs your help.
You seem to believe ICANN has a much greater role in Internet management than it has. ICANN can't even make changes to a name server in the root zone without US government approval.
How about some funding for research projects? Getting involved and perhaps funding Incident response on a global scale?
I can suggest this, although having a concrete proposal would probably carry more weight.
Why does this have to be in the hands of volunteers, such as myself and hundreds of others?
Why does Internet security have to be in the hands of those with "good will" rather than those who are supposed to take care of it?
I suspect because the Internet is decentralized.
How about adding security to the main agenda along-side with the .xxx TLD?
It is, although there are lots of aspects to security so undoubtedly, it can't be all things to all people. ICANN has an advisory committee specifically targeted at "security and stability" that has some folks who frequently participate on this list (http:// www.icann.org/committees/security/).
I have no problem with ICANN, but there is a long way to go before you can claim to protect the Internet, infrastructure, users, or what's in the middle.
I don't think ICANN claims this.
I'd encourage ICANN to take that road, much like I would encourage any person or organization that wants to help.
You were not here before when we needed you, so organizations like FIRST, the ISOTF and many good-will based groups were created. You are here now, how do we proceed?
I don't think anyone expected ICANN to take on the role of Internet security czar. I suspect if ICANN tried to assert this sort of role, the USG (among other governments) would take strong exception. ICANN's role (as I understand it) is coordinative, not directive. Any attempt to go beyond this will result in ICANN getting slapped down.
What is ICANNs next step? I will support it, so will others. It's not about politics as much as it is about who DOES. Maybe you just need to work with the community rather than claim to run it when you don't really do anything in security quite yet.
I don't think ICANN has ever claimed to run "the community".
Well, if a domain was registered last month, last week, or 2 hours ago, and is used to send spam, host a phishing site or changes name servers that support phishing sites ALONE (nothing legit) in the thousands, or support the sending of billions of email messages burdening messaging across the board, I'd call it bad.
As would I.
Who "one" is, now that is something to work out. We need help setting the system in place with guidelines and policies so that the one or other can start reporting and getting results.
Is ICANN willing to help?
To be perfectly clear, I don't speak for ICANN, I just run IANA. I'm happy to forward suggestions to folks in ICANN who don't participate in NANOG or other forums, but don't expect this to have significantly more impact than you participating directly in the various ICANN forums.
Rgds, -drc
On 3 Apr 2007, at 03:02, Gadi Evron wrote:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
I don't like this because its impossible to define abuse clearly enough in this context. If a fictitious web-shop 'nice-but-dim.com' get a box owned which has the reverse dns set to something in that zone, is this abuse ? Yes .. sort of, but it's no business of the registry. Is registering a domain name which causes offense to some people abuse ? It might be, but its no reason not to let the domain name registration go through. What if you and I fall out, and I manage to build a case against you to get linuxbox.org de-registered ? Do you want to spend time and effort fighting it ? Who arbitrates/polices this scheme ? Who pays for any mistakes ? Who decides when the domain name can be re-registered ? What about when someone registers a domain name in an international registry that doesn't want to implement the scheme, or perhaps isn't allowed to because its governance forbids it ? Some bad people have their names and numbers listed in the phone book. I can setup a fraudulent window cleaning company with no desire to do a good job for any of my customers .. does this mean 411 or the yellow pages should delist me when someone complains ? DNS is another directory. DNS is no more than a way for me to say "Hey, where's Fred', to get a reply saying 'here he is'. DNS shouldn't whisper in my ear, 'but Fred is a bit dodgy'. If Fred is doing something illegal he should be in jail. This analogy isn't very good, but I need another coffee before I can think of a better one. :-) -a
On Tue, 3 Apr 2007, Andy Davidson wrote:
On 3 Apr 2007, at 03:02, Gadi Evron wrote:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
I don't like this because its impossible to define abuse clearly enough in this context.
If a fictitious web-shop 'nice-but-dim.com' get a box owned which has the reverse dns set to something in that zone, is this abuse ? Yes .. sort of, but it's no business of the registry. Is registering a domain name which causes offense to some people abuse ? It might be, but its no reason not to let the domain name registration go through. What if you and I fall out, and I manage to build a case against you to get linuxbox.org de-registered ? Do you want to spend time and effort fighting it ?
Who arbitrates/polices this scheme ?
Who pays for any mistakes ?
Who decides when the domain name can be re-registered ?
What about when someone registers a domain name in an international registry that doesn't want to implement the scheme, or perhaps isn't allowed to because its governance forbids it ?
Now that we ask the questions, prhaps we can come up with *some* answers.
Some bad people have their names and numbers listed in the phone book. I can setup a fraudulent window cleaning company with no desire to do a good job for any of my customers .. does this mean 411 or the yellow pages should delist me when someone complains ? DNS is another directory.
DNS is no more than a way for me to say "Hey, where's Fred', to get a reply saying 'here he is'. DNS shouldn't whisper in my ear, 'but Fred is a bit dodgy'. If Fred is doing something illegal he should be in jail. This analogy isn't very good, but I need another coffee before I can think of a better one. :-)
-a
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
I don't like this because its impossible to define abuse clearly enough in this context.
If a fictitious web-shop 'nice-but-dim.com' get a box owned which has the reverse dns set to something in that zone, is this abuse ? Yes .. sort of, but it's no business of the registry. Is registering a domain name which causes offense to some people abuse ? It might be, but its no reason not to let the domain name registration go through. What if you and I fall out, and I manage to build a case against you to get linuxbox.org de-registered ? Do you want to spend time and effort fighting it ?
Who arbitrates/polices this scheme ?
Who pays for any mistakes ? I think the shutdown of seclists.org by GoDaddy is a perfect example of exactly why the registrars should NOT be making these decisions.
And exactly what good is 24 hour notice (as some people have suggested) going to do? With 2 million domains registered every single day (according to a recent techworld article) who could possibly go through such a list and make informed decisions? If you want a really simple, and probably very effective first step- then stop domain tasting. It doesn't help anyone but the phishers. An even better idea would be for companies to send out their own phishing emails. Every user that falls for it gets an email/phone call informing them just how stupid they are and notifying them that if they fall for it again they are going to lose their account. The next time fall for it you shut down their account. Seriously though- why do we keep blaming the infrastructure for the mind boggling stupidity of users? -Don
I think the shutdown of seclists.org by GoDaddy is a perfect example of exactly why the registrars should NOT be making these decisions.
I know the head abuse guy at Godaddy. He is a reasonable person. He turns off large numbers of domains but he is human and makes the occasional mistake. The fact that everyone cites the same mistake tells me that he doesn't make very many of them. If you demand that the shutdown process be perfect and never make any mistakes ever, even ones that involve peculiar e-mail failures are are fixed in a day or two, you're saying there can't be any shutdown process at all.
If you want a really simple, and probably very effective first step- then stop domain tasting. It doesn't help anyone but the phishers.
Actually, I have never seen any evidence that phishers use domain tasting. Phishers use stolen credit cards, so why would they bother asking for a refund? The motivation for tasting is typosquatting and "monetization", parking web pages full of pay per click ads on them. Tasting is a bad idea that should go away, but phishing isn't the reason. R's, John
I know the head abuse guy at Godaddy. He is a reasonable person. He turns off large numbers of domains but he is human and makes the occasional mistake. The fact that everyone cites the same mistake tells me that he doesn't make very many of them. We cite this one because it was such an unbelievable cock-up it wasn't funny. Fyodor a blackhat? Seclists.org a malicious site? Honest to god did
the guy do even the teensiest little bit of due diligence before shutting the site down? I don't believe he did. There have been plenty of other examples of GoDaddy deleting stuff they shouldn't have. Seclists.org just takes the cake. An even better question would be why doesn't he read seclists.org in the first place? It would be an excellent way to keep on top of security problems- something someone in your friends position should probably be doing.
Actually, I have never seen any evidence that phishers use domain tasting. Phishers use stolen credit cards, so why would they bother asking for a refund? The motivation for tasting is typosquatting and "monetization", parking web pages full of pay per click ads on them. Tasting is a bad idea that should go away, but phishing isn't the reason. I agree that typosquatters and the like are the primary reason and that it should go away. As for the phishers- fine- say the problem is stolen credit cards. What then is the solution?
-Don
We cite this one because it was such an unbelievable cock-up it wasn't funny. Fyodor a blackhat? Seclists.org a malicious site? Honest to god did the guy do even the teensiest little bit of due diligence before shutting the site down?
He screwed up, we all know that. My point is that human processes are not infallible, and there's no reason to think that any process we may care to define is likely to be any better overall than the one they have now. If he were much more careful, and that meant that a thousand spam/phish domains stayed up for an extra week every year to avoid a two-day mistaken turndown, would that be better overall?
I agree that typosquatters and the like are the primary reason and that it should go away. As for the phishers- fine- say the problem is stolen credit cards. What then is the solution?
If it were up to me, I would put the price of domains back up to $100, and make them all take a month to get into the DNS. The whole idea that everyone needs a 2LD is utterly broken. But good luck putting that genie back into the bottle. R's, John
I know the head abuse guy at Godaddy. He is a reasonable person. He turns off large numbers of domains but he is human and makes the occasional mistake. The fact that everyone cites the same mistake tells me that he doesn't make very many of them.
Hm, okay, which one was that. Was it: o nectartech.com o berlettefx.com o foetry.com o familyalbum.com And I'm not even trying hard. But be sure to let me know which one is the one everyone cites so that I can be sure to be with the "in" crowd. ;-)
If you demand that the shutdown process be perfect and never make any mistakes ever, even ones that involve peculiar e-mail failures are are fixed in a day or two, you're saying there can't be any shutdown process at all.
The Internet is a wonderful place to be. We can get redundant circuits through diverse providers and get BGP to make it all work for us. We can put geographically diverse nameservers around the globe to ensure that a network failure doesn't make our DNS stop resolving. But there's no redundancy for a DNS registration. As a result, things involving a DNS registration should probably require a /higher/ level of diligence, rather than a lower level. Many of the experiences like the whole seclists thing rank right up there with the experience I had with Cogent filtering one IP address of a client's /24 due to a Usenet spam complaint, at around 3AM in the morning, with a 1 hour "mandatory response window", where they didn't give any return contact information, AND not only did they not succeed in mitigating the "problem" (because they didn't understand that the message had been posted many hours earlier) but they didn't even filter the right IP address. Except that was harmless. Competence is always in short supply, but it is in particularly short supply where the margins are thin. Domain names are one really stellar example of something that is both critical and has little profit margin. We should be very careful about wishing for domain registrars to "fix" problems, because the results are not likely to be what you think. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Seriously though- why do we keep blaming the infrastructure for the mind boggling stupidity of users?
There will always be users that don't understand technology. You call them stupid, I call them mom & dad, brother & sister. If you maintain the attitude that it is the 'stupid' users fault the Internet is insecure then you will never see a secure Internet. The Infrastructure must be able to protect itself from its users. It isn't that hard to throw a outbound port 25 filter on your edge and force all of your users to send mail through your mail server. It isn't that hard to require SMTP_AUTH for all mail transactions on that server. It also isn't that hard to deploy a snort box to look for 'bad' traffic and kick the users PPPoE session offline. We need a 'drivers license' for the 'information super highway' companies/ISPs must be able to show a certain level of competency before they can buy bandwidth from the 'Internet'. If they don't have that competency then they need to purchase it from an ISP that can provide the competency. It is the ISPs job to protect the network from its users (IMHO). If it really concerns you, protect your corner of the IP world, run an IDS find the 'bad' traffic and dynamically update your BGP sessions to null route the ASNs you don't feel 'do the right thing'. If you get good enough at it maybe you could publish a eBGP feed of the 'ASNs I don't like' and people can subscribe to it. Sure there will be some pain, but when you swing a big axe, there is bound to be some blood. -Matt -- Matthew S. Crocker President Crocker Communications, Inc. Internet Division PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com
Gadi Evron wrote:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
Are you crazy or what? Ever heard of due process? What is abuse? Who decides that? Office of pre-crime? In the end the cure is worse than the diseas (by abusing the anti-abuse system. DMCA abuse anyone? Or the stupid bogons list so many people forget to update every friggin time IANA allocated a new /8 to one of the RIRs?)
3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core?
Never ever should anything like that be done at the core. Especially when you try to fix a problem that isn't even at the core but in one vendors operating system without a proper fix after having known it for more than five month. Gadi, you're barking up the wrong tree. Try to hit Microsoft instead. -- Andre
On Tue, 3 Apr 2007, Andre Oppermann wrote:
Gadi Evron wrote:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
Are you crazy or what? Ever heard of due process? What is abuse? Who decides that? Office of pre-crime?
Now you're talking. What *would* be due process, and if it happens, how do we follow up?
In the end the cure is worse than the diseas (by abusing the anti-abuse system. DMCA abuse anyone? Or the stupid bogons list so many people forget to update every friggin time IANA allocated a new /8 to one of the RIRs?)
3. For true emergencies threatening the survivability of the system, shoudln't we be able to black-list a domain in the core?
Never ever should anything like that be done at the core. Especially when you try to fix a problem that isn't even at the core but in one vendors operating system without a proper fix after having known it for more than five month.
Gadi, you're barking up the wrong tree. Try to hit Microsoft instead.
-- Andre
In the end the cure is worse than the disease (by abusing the anti-abuse system. DMCA abuse anyone? Or the stupid bogons list so many people forget to update every friggin time IANA allocated a new /8 to one of the RIRs?)
It's interesting to see how bandaid solutions increase the problems because they are too weak to solve the issue that they are targetted at, create additional issues of their own, and spawn a herd of imitators with similar bandaid solutions. And on it goes... --Michael Dillon
The one concrete suggestion I've seen is to induce a delay in zone creation and publish a list of newly created names within the zone. The problem with this is that is sort of assumes:
What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details.
This is very, very dangerous. Registrars such as GoDaddy who have tried this could be well-meaning, but are not in the correct position to be able to reliably determine what is going on. What constitutes abuse? You received a spam message with our domain forged in the headers? You received a spam message with one of our IP's and domain names forged in the headers (this is becoming common)? You received one actual spam because some customer installed their own web-to- mail script on the web server and it got 0wn3d? Someone got their web server here 0wn3d and it is acting as a controller for pr0n/etc spam spewing bots? What constitutes a fraudulent registration? No phone number? An old phone number? A current phone number where the SIP registration has failed because the VoIP provider made some changes? A current phone number that isn't answered? No address? An old address? And so on... I'll remind you that in all of these cases, removing a domain name is not going to be mitigation. It might *feel* good but it has the potential to do lots of damage for little result. Is there a difference between a decade-old domain with contact information where a web server got hacked, and a 1-day old domain with garbage for contact information that was set up explicitly for Bad Stuff? How do you tell?
5. Enforcing that registrars act in say, not a whitehat fashion, but a not blackhat fashion?
"Whitehat" does not mean what many seem to think. A whitehat would have the philosophy of trying to take the course of action that was the most equitable and did the least amount of harm possible. Many people have equated "whitehat" to mean "we nuke things when problems are reported," and that isn't whitehat - that's simply stupidly malicious. I would go so far as to call the reported behaviour of registrars such as GoDaddy to be virtually blackhat. Look at this crud: http://domainnamewire.com/2007/02/28/godaddy-responds-to-deletion-over-inval... So, *knowing* that the contact e-mail wasn't working, they sent requests for current contact info *to* the broken contact e-mail. When they didn't get a response, they then didn't bother calling or writing via snail mail, which were apparently valid, but instead cancelled the domain and then sold it to someone who had paid for backorder, so they've collected twice for the domain *and* then also for the backorder. Profitable for them. As far as I'm concerned, also highly unethical. A whitehat would have called. A whitehat would have written a letter. A whitehat would have even gone to the web site to look for further contact info. A whitehat that felt action was mandatory would have suspended the domain (not redirected, merely suspended) as a way to try to get the domain holder to contact. This is essentially a big loophole in 3.7.7.2. GoDaddy can probably make a reasonably valid claim that they followed the ICANN policy, and yet it is obvious that they didn't really do anything sensible in this case. So to get back to Gadi's point #1, if they can't even do a reasonable job of terminating for incorrect information in domain registrations, do we really want registrars trying to handle abuse? (Note that GoDaddy has some bad history here too, see seclists.org for example). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, Apr 03, 2007, Joe Greco wrote:
Is there a difference between a decade-old domain with contact information where a web server got hacked, and a 1-day old domain with garbage for contact information that was set up explicitly for Bad Stuff? How do you tell?
Yup! One was registered a day ago and is now sending out loads of spaff. Best people to know which domains are involved in sending out spaff? Hotmail? Yahoo? AOL? Google? You know, those people who run millions and millions of email accounts and can do rather scary statistical analysis on email.. I wonder if any of the above would be interested in reporting spam-sending hosts, URLs involved in spam/phish/scam/etc/ to a public group (or semi-public group - open to join, but not publicly published) who could start working on feeding these domains back to registrars? Adrian
On Tue, Apr 03, 2007, Joe Greco wrote:
Is there a difference between a decade-old domain with contact information where a web server got hacked, and a 1-day old domain with garbage for contact information that was set up explicitly for Bad Stuff? How do you tell?
Yup! One was registered a day ago and is now sending out loads of spaff.
It was a trick question. The next question is "how do you differentiate"? I took two obvious cases and compared them. In such a case, it should be reasonably obvious to the average person what the answer is. The problem is that it is rarely so clear. Take the example of what happened to seclists.org. Surely it looked like a legitimate complaint, didn't it? You have a big company like MySpace that has submitted a complaint claiming that a bunch of user passwords have been posted on the seclists.org web site. Go to web site, sure enough. Maybe look at registry info, see "insecure.com" mentioned, maybe think it is some hacker web site. So shut it down. The problem here is that any competent abuse department should have done more research and laughed this into the circular file. This is the costly bit that a domain registrar isn't going to be likely to do. First, analysis of the complaint itself. Passwords - on seclists.org web site. Okay. 1) Realize that the web site is an archival copy of a mailing list. This means that heavy distribution has already happened, and any ancillary distribution happening by the web site is incidental. 2) Because heavy distribution has already happened, the passwords in question are not in any way "protected" by removing them from the web page (or removing the web page). 3) Notice that the data has already been posted on *other* web sites. Conclusion #1 --> MySpace has a serious data breach on its hands. Distribution is wide on visible community resources. This implies much heavier distribution is likely on invisible blackhat resources. Appropriate mitigation steps involve disabling and re-passwording all accounts. Conclusion #2 --> Continued listing of the passwords on the web site is minimally harmful. Stand by for further processing. Answer #1 to MySpace --> "Disable these accounts, your password list has been widely distributed." Further analysis: visit http://www.seclists.org. Notice the words "security mailing list archive." Attempt to verify that it is what it appears to be. Conclusion #3 --> Given a security mailing list, one would expect that there would be some discussion of current security problems. The inclusion of an actual password list may have been in mildly poor taste, but it is not due to deliberate intent of the website's operator. Since the password list is already public and heavily distributed, it might be reasonable to request the web site owner to remove the archive page pending a response from MySpace that the passwords had been disabled. Answer #1 to seclists.org -> "Disable this web page pending further developments." This is one reasonable resolution to the issue. I won't pretend it is the only possible "whitehat" course of action, but there is no whitehat course of action that ends with "seclists, we're suspending your domain." If you do not have clear and obvious things to judge, analysis of a situation becomes even more difficult. The above is not going to be something that a first level support lackey is going to be able to work out on his own... so that implies paying people who are skilled (and who incidentally would probably have been on seclists mailing lists, haha) Right now, 1-day-old domains are a problem because nobody has a compelling reason to let abuse domains age prior to using them. If it becomes common policy for major providers to require domains to have existed for a certain amount of time before they accept mail (as one example) containing that domain name, then bad actors will simply register domains, allow them to age, and then use them later. I am not seeing easy solutions. I am seeing costly solutions that involve a lot more involvement on the part of registrars. The obvious flags of trouble (such as "1-day-old") are at best only useful in the short term, because the bad actors can and will adapt.
Best people to know which domains are involved in sending out spaff? Hotmail? Yahoo? AOL? Google? You know, those people who run millions and millions of email accounts and can do rather scary statistical analysis on email..
You trust Hotmail? One of our businesses here has a mail server running on a clean IP (an IP that had never before been used for mail in the history of the Internet, and had been inactive for several years in any case). It exclusively sends a very low volume of support replies and the occasional billing problem. All mail is text - not HTML. There are no images. There are no advertisements. Hotmail is silently dropping every one of those messages sent to them. Not junk folder. Dropping. Explain *that*. While Hotmail *could* be bothered to do what you suggest, and I am sure that it is an incredibly difficult task to handle a freemail system like theirs, they're not doing it. Surely they've learned a lot of neat stuff about dropping problematic e-mail, but they're also dropping legitimate mail, so let's be real. Their priority isn't accurately determining what domains are spamming. Their priority is running a heavily attacked freemail provider without a trillion dollar budget. There is some overlap, but only some. We take in several megabits of traffic to our spam traps here, and I bet we (and anyone like us, since there's a bunch of folks who do the same) could generate some stats. I don't have time for any more projects though.
I wonder if any of the above would be interested in reporting spam-sending hosts, URLs involved in spam/phish/scam/etc/ to a public group (or semi-public group - open to join, but not publicly published) who could start working on feeding these domains back to registrars?
If the registrars were interested in doing anything with the data, I believe there are already some groups doing the collection of such data. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
This is the costly bit that a domain registrar isn't going to be likely to do.
Well, you're not likely to get it for the $8.95 that Godaddy charges. Their abuse department does a remarkably good job, considering their volume and margins. Perhaps the message here is that you get what you pay for. For a rock bottom price, You get rock bottom service. There are registrars that charge considerably more and provide considerably more service. ObOperations: I need a 1.5Mb net connection. I'm planning to pay $29.95/month, since I see lots of ads on TV for places offering that. Oh, and I expect five nines reliability and you can bet I will complain loudly and bitterly when I call in an outage at 3 AM and get the answering machine. R's, John
I was wondering if a few folks on this list could look at a problem I'm seeing. I've poked around most of yesterday and this morning and initially I thought it was a dns problem but it appears to me that www.airfrance.com is blocking a whole lot of the IP space in the US from accessing their website. Using proxy servers I find that ATT network, my network are both blocked but roadrunner can access their website. Can you? Can a few of you check from wherever you are and see if I'm correct in my assessment of the problem? George Roettger Netlink Services www.nls.net
On 4/3/07, Geo. <geoincidents@nls.net> wrote:
I've poked around most of yesterday and this morning and initially I thought it was a dns problem but it appears to me that www.airfrance.com is blocking a whole lot of the IP space in the US from accessing their website. Using proxy servers I find that ATT network, my network are both blocked but roadrunner can access their website. Can you?
AF has country-specific front pages. Airfrance.com, the generic corporate site, is OK from here; Airfrance.us is reachable from London (if you lie:-)) but extremely slow loading. Airfrance.fr is OK. Airfrance.co.uk is slow but OK. 1 1 1 0 0.7 ms 66.36.240.2 AS14361 HOPONE-DCA c-vl102-d1.acc.dca2.hopone.net. 255 US Unix: 15:25:04.988 2 0 0 1 0.7 ms [+0ms] 66.36.224.248 AS0 IANA-RSVD-0 gec3.core1.dca2.hopone.net. 0 miles [+0] 254 US Unix: 16:24:46. 18 3 5 3 1 1.4 ms [+0ms] 66.36.224.18 AS0 IANA-RSVD-0 ge3-0.core1.iad1.hopone.net. 0 miles [+0] 253 US Unix: 15:26:48.426 4 3 1 1 1.5 ms [+0ms] 66.36.224.178 AS0 IANA-RSVD-0 ge-3-0-0.ashbb2.ashburn.opentransit.net. 0 miles [+0] 252 US Unix: 15:24:25. 45 5 3 1 2 1.5 ms [+0ms] 193.251.243.141 AS5511 OPENTRANSIT gi4-0-0.ashcr1.ashburn.opentransit.net. 0 miles [+0] 251 FR [Router did not respond] 6 * 82 81 81 ms [+80ms] 193.251.242.97 AS5511 OPENTRANSIT po6-0.pascr3.paris.opentransit.net. 0 miles [+0] 250 FR [Router did not respond] 7 120 82 82 82 ms [+0ms] 193.251.129.61 AS5511 OPENTRANSIT po9-0.pascr1.paris.opentransit.net. 0 miles [+0] 249 FR [Router did not respond] 8 128 83 84 82 ms [+0ms] 193.251.126.57 AS0 IANA-RSVD-0 pos15-0.ntsta202.paris.francetelecom.net. -1 miles [+0] 0 miles [+0] 248 FR [Router did not respond] 9 154 82 82 82 ms [+0ms] 193.251.126.70 AS0 IANA-RSVD-0 po14-0.ntsta302.paris.francetelecom.net. -1 miles [+0] 0 miles [+0] 247 FR [Router did not respond] 10 97 88 89 88 ms [+6ms] 193.251.126.93 AS0 IANA-RSVD-0 pos0-3-0-0.nrlyo302.lyon.francetelecom.net. -1 miles [+0] 0 miles [+0] 245 FR [Router did not respond] 11 150 96 96 96 ms [+7ms] 193.252.101.149 AS0 IANA-RSVD-0 po9-2.ncmar302.marseille.francetelecom.net. -1 miles [+0] 0 miles [+0] 245 FR [Router did not respond] 12 150 96 96 96 ms [+0ms] 193.253.14.102 AS0 IANA-RSVD-0 pos-4-0.marg2.marseille.raei.francetelecom.net. -1 miles [+0] 0 miles [+0] 244 FR [Router did not respond] 13 124 100 100 98 ms [+2ms] 81.52.15.234 AS0 IANA-RSVD-0 atm-6-0-0-732.sph2.sophia.raei.transitip.francetelecom.net. -1 miles [+0] 0 miles [+0] 241 FR [Router did not respond] 14 120 104 102 98 ms [+0ms] 81.54.114.30 AS0 IANA-RSVD-0 unknown.rain.fr -1 miles [+0] 0 miles [+0] 241 FR [Router did not respond] 15 121 100 106 98 ms [+0ms] [192.168.x.x] AS16559 REALCONNECT-01 [Internal] -1 miles [+0] 0 miles [+0] 241 [??] [Router did not respond] 16 * * 106 98 ms [+0ms] [192.168.x.x] AS16559 REALCONNECT-01 [Internal] -1 miles [+0] 0 miles [+0] 238 [??] [Router did not respond] 17 * * * 98 ms [+0ms] [Unknown] [Unknown - Firewall did not respond] -1 miles [+0] 0 miles [+0] 18 * * 98 98 ms [+0ms] 193.57.244.15 AS25186 TRANSIT-VPN-AS [Reached Destination]double6.airfrance.fr.
AF has country-specific front pages. Airfrance.com, the generic corporate site, is OK from here; Airfrance.us is reachable from London (if you lie:-)) but extremely slow loading. Airfrance.fr is OK. Airfrance.co.uk is slow but OK.
So far everyone who responded has managed to get the site to come up. When I go to www.airfrance.com from anywhere in my network 216.144.0.0/18 I simply get a timeout using anything including telnet to port 80, see below 15 297ms 299ms 299ms pos9-0.ncmar302.Marseille.francetelecom.net [193.252.101.53] 16 300ms 295ms 300ms pos-4-0.marg2.marseille.raei.francetelecom.net [193.253.14.102] 17 306ms 301ms 296ms atm-6-0-0-732.sph2.sophia.raei.transitip.francetelecom.net [81.52.15.234] 18 306ms 298ms 307ms 81.54.114.30 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 ^C g:\>telnet 193.57.244.15 80 Connecting To 193.57.244.15...Could not open a connection to host on port 80 : C onnect failed If anyone has any ideas I'm all eyes. George Roettger Netlink Services www.nls.net
On 4/3/07, Geo. <geoincidents@nls.net> wrote: So far everyone who responded has managed to get the site to come up. When I
go to www.airfrance.com from anywhere in my network 216.144.0.0/18 I simply get a timeout using anything including telnet to port 80, see below
15 297ms 299ms 299ms pos9-0.ncmar302.Marseille.francetelecom.net [193.252.101.53] 16 300ms 295ms 300ms pos-4-0.marg2.marseille.raei.francetelecom.net [193.253.14.102] 17 306ms 301ms 296ms atm-6-0-0-732.sph2.sophia.raei.transitip.francetelecom.net [81.52.15.234]
That's almost certainly Sophia-Antipolis - a big location for data centres, including France Tel and IBM Global Services, between Nice and Cannes.
This is the costly bit that a domain registrar isn't going to be likely to do.
Well, you're not likely to get it for the $8.95 that Godaddy charges. Their abuse department does a remarkably good job, considering their volume and margins.
Most places are selling domains for around that price. It was GoDaddy's decision to try to handle abuse in this manner. If they can't do it at this price point, why is that a problem that their customers should have inflicted on them? So do you really think that the true abusers are getting nuked? Or is it more likely that they register a name at GoDaddy, get nuked once, and then go elsewhere for future activities? That means that the volume of legitimate complaints at GoDaddy ought to be somewhat lower than at their competitors, which simultaneously means that they would *need* to be doing a much better job of analysis, or they risk closing down legitimate domains more often.
Perhaps the message here is that you get what you pay for. For a rock bottom price, You get rock bottom service. There are registrars that charge considerably more and provide considerably more service.
Personally, I don't consider "submit a spam complaint and get someone's domain taken down without due diligence" to be a service. However, I guess I can make an exception and agree that GoDaddy is offering "rock bottom service."
ObOperations: I need a 1.5Mb net connection. I'm planning to pay $29.95/month, since I see lots of ads on TV for places offering that. Oh, and I expect five nines reliability and you can bet I will complain loudly and bitterly when I call in an outage at 3 AM and get the answering machine.
Sometimes that happens for hicap circuits too. Don't get me started about the provider that "only does BGP from 9 to 5." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Perhaps the message here is that you get what you pay for. For a rock bottom price, You get rock bottom service. There are registrars that charge considerably more and provide considerably more service.
There just isn't enough hierarchy in the DNS. Back when I was running my own ISP, I gave hosting customers free domain names like bobscafe.myisp.net, and fredshardware.myisp.net. That was a rockbottom price but because it was bundled with another product and FULLY UNDER MY CONTROL, I could do it for free. It cost more money, $50 I believe, to register a name like myisp.net. But unfortunately, it was darn near impossible to register a new TLD unless you were a small country. That is where the problem started. The charging structure should have been hierarchical so that people could register a new TLD (4 chars or more) for $1 million, and a new second level domain for $1000. That would have driven smaller businesses to 3rd level domain names which would probably range from free-with-hosting-service to $5 a year with DNS hosting thrown in. Now we have this horrible flat system where 3 char TLDs are free but require a bloated and expensive evaluation process, 4 char and greater TLDs do not exist, and everyone is crammed in on the 2nd level with far too many trying to pretend that they have a TLD inside .com. Blechhh! Only one registry out there http://www.nic.name/ is even doing third level registrations and most ISPs no longer give out meaningful third level names, just stuff like cs182365536663.myhosting.net and the like. What ICANN is missing, sorely missing, is an office of the CTO which would look at naming and addressing *ARCHITECTURE* and advise the board and ICANN councils. Eventually, we could have some intelligent discussion of a better way to structure this whole thing and then we would at least have a goal that we could work towards in fits and starts. Instead of the floundering that happens today. I remember when we had the IAHC and it seemed like we really would have some system that was based on sound network architectural grounds. Unfortunately, ICANN was formed to wrestle with the political issues and left the technical issues sitting in a cloud of dust back at the busstop. --Michael Dillon
Well, you're not likely to get it for the $8.95 that Godaddy charges. Their abuse department does a remarkably good job, considering their volume and margins.
Perhaps the message here is that you get what you pay for. For a rock bottom price, You get rock bottom service. There are registrars that charge considerably more and provide considerably more service.
The problem here is that the community gets screwed not the guy paying $8.95. If he was getting what he paid for- well who cares. The problem is everyone else. That said- even if domains were more expensive it wouldn't change anything for the phishers using their stolen credit cards. There simply needs to be a better way for the community to quickly identify phishing sites- verified by some independent body (such as CERT) that can quickly verify the domain is a phishing site and alert the registrars to shut them down. Don't let it be used for copyright or any other non-sense complaint. -Don
On Tuesday 03 April 2007 18:35, Donald Stahl wrote:
The problem here is that the community gets screwed not the guy paying $8.95. If he was getting what he paid for- well who cares. The problem is everyone else.
At the risk of prolonging a thread that should die.... Gadi forwarded a post suggesting DNSSEC is unneeded because we have security implemented elsewhere (i.e. SSL). Thus how does it affect me adversely if someone else registers a domain, if I don't rely on the DNS for security? Much of the phishing I see is hosted on servers that have been compromised, I guess that is cheaper than the $8.95 for a domain. If there is evidence that domain tasting is being used for abusive practices, I'm sure the pressure to deal with it will increase. Much as I think the practice is a bad thing, I don't see it as a major security issue. The reason domain registration works quickly, is that it was a real pain when they didn't (come on it wasn't that long ago). People registering domains want it up and running quickly, as humans aren't good at the "I'll check it all in 8 hours/2 days/whatever". I'm sure prompt registration/activation/changes of domains is in general a good thing, resulting in better DNS configurations. Sure it is possible domains will be registered for abusive activity, and discarded quickly, with a difficult path in tracing such. But if there is some sort of delay or grace period it won't make a difference. When domains took days to register spammers waited days. I don't suppose phishers are any less patient. Validation of names, addresses, and such like is impractical, and I believe inappropriate. There is a method for such validations (purchase of SSL certificates), and even there the software, methods, and tools are pitiful. Why should the domain registrars be expected to do the job (or do it better?), when it could be equally argued that ISPs are is a better position to police the net. The credit card companies are good at passing chargeback fees to the vendor, so be assured if people are using fraudulent credit card transactions, the domain sellers will have motivation to stop selling them domains. The essential problem with Internet security is that there is little come back on abusers. There have been obvious and extensive advanced fee fraud run from a small set of IP addresses in Europe, using the same national telecomm provider as a mail relay, and it took 4 years to get any meaningful action (I assume the recent drying up of such things was a result of action, the fraudster may just have retired with their ill gotten gains for all I know!). There are specific technical, and market issues, but without any real world policing, the abusers will keep trying, till either they succeed or go bust. If they succeed they may well go on to become part of more organized abuse. The other problem is that their is no financial incentive for ISPs to do the "right thing". Where as domain registrars can cancel a domain, and get another sale from the same abuser - so they have a financial incentive to clean up. If ISPs close an account, the person will likely just switch ISP. A classic example I commented on recently was "Accelerate Biz", unrepentant spammers (at least their IP address range is from here, either that or so thoroughly incompetent they might as well be). Their inbound email service is filtered by "Mail Foundry", but despite being an "antispam" provider, Mail Foundry have no financial incentive to stop providing services to these spammers. Till companies (ISPs included) are fined for providing such services, so it isn't profitable, we'll be spammed. Port 25 SYN rate limiting isn't that much harder than ICMP ;) Simon, speaking in a personal capacity, views expressed are not necessarily those of my employers.
On Apr 2, 2007, at 6:29 PM, David Conrad wrote:
On Apr 1, 2007, at 8:45 AM, Gadi Evron wrote:
On Sun, 1 Apr 2007, David Conrad wrote:
On Mar 31, 2007, at 8:44 PM, Gadi Evron wrote: I'm not clear what "this realm" actually is. Abuse and Security (non infrastructure).
Well, ICANN is supposed to look after the "security and stability" of the Internet, which is sufficiently vague and ambiguous to cover pretty much anything. I was actually looking for something a bit more concrete.
The one concrete suggestion I've seen is to induce a delay in zone creation and publish a list of newly created names within the zone. The problem with this is that is sort of assumes:
a) the registries all work on similar timescales b) that timescale is on the order of a day c) ICANN has a mechanism to induce the registries to make changes to those timescales d) making changes along these lines would be what end users actually want.
Of these options:
- (a) isn't true (by observation) - (b) is currently true for com/net, but I don't expect that to last -- I've heard there is a lot of competitive pressure on the registries to be faster in doing zone modifications - (c) I don't think is true now for even those TLDs ICANN has a contractual relationship with and is highly unlikely to ever be true for the vast majority of TLDs - (d) probably isn't true, given lots of people complain about how long it takes to get zone changes done now and I believe registries are working to reduce the amount of time significantly due to customer demand.
Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
Good points. The suggestion was to preview the addition of domains 24 hours in advance of being published. This can identify look-alike and cousin domain exploits, and establish a watch list when necessary. A preview provides valuable information for tracking bad actors and for setting up more effective defenses as well. Should a 24 hour delay on updates prove unworkable, one method might be to flag new domains. The flag would cause the record to remain hidden until the flag is removed. Perhaps IN could be set to something else as a signal the record is being previewed. The registrar would not see the flag, but would see the information as it would appear when finally published. Nothing should appear different from the registrar's perspective. It would also be good to establish feeds to interested parties of modifications as they occur. Currently domain name additions are accomplished in milli-seconds, but then reported after 24 hours. This agility is being heavily abused by bad actors hiding within the daily churn of millions of new domains. A preview mode of operation offers a viable defensive tactic that should not impose much in the way of additional costs. -Doug
On Apr 2, 2007, at 10:27 PM, Douglas Otis wrote:
The suggestion was to preview the addition of domains 24 hours in advance of being published. This can identify look-alike and cousin domain exploits, and establish a watch list when necessary. A preview provides valuable information for tracking bad actors and for setting up more effective defenses as well.
And just how many humans would this require? Or are you going to write a 12-kilobyte regex in Perl to do the work for you? Do you know how many trademarks and words that represent companies there are in existence? What about local lingo that might be misleading--like if you weren't familiar with college sports and thus "officialNittanyLions.com" (contrived example) didn't raise any red flags with you? I could see perhaps a flag or a standard value to go into TXT (maybe part of the exiting SPF conventions) that indicate the age of the domain. Then leave it up to the user as to what to do with that information (a mail server not allowing emails from domains less than 15 days old for example). [True Story: I had a client who was a pastor of a church. One time he calls me because somebody had used his computer, which was in his locked office, to surf what he was sure was "some kind of sick, filthy site". What had actually happened was that the guy fixing his machine the night before (who had a key to all the offices) had left up a browser for the popular tech-tips site ExpertsExchange.com . The pastor, not having heard of the site, read the lowercase site name in the browser bar as "ExpertSexChange.com". ]
On Mon, 2 Apr 2007, David Conrad wrote:
Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
A good start would be to forbid the delegation of newly-registered domains that have not yet been paid for. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ HEBRIDES BAILEY: NORTH OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD.
On Tue, Apr 03, 2007, Tony Finch wrote:
On Mon, 2 Apr 2007, David Conrad wrote:
Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
A good start would be to forbid the delegation of newly-registered domains that have not yet been paid for.
Define paid for. Paid for == bank said yes, or Paid for == bank said yes and then said "Whoa no; thats not really right." (I truely wonder what the domain registrars are seeing as CC transaction failure rates, and why the banks haven't stepped in.) Adrian
On Tue, 3 Apr 2007, Adrian Chadd wrote:
On Tue, Apr 03, 2007, Tony Finch wrote:
On Mon, 2 Apr 2007, David Conrad wrote:
Even if a delay were imposed, I'm not sure I see how this would actually help as I would assume it would require folks to actually look at the list of newly created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
A good start would be to forbid the delegation of newly-registered domains that have not yet been paid for.
Define paid for. Paid for == bank said yes, or Paid for == bank said yes and then said "Whoa no; thats not really right."
(I truely wonder what the domain registrars are seeing as CC transaction failure rates, and why the banks haven't stepped in.)
The banks don't lose enough money to warrant action, at least action specific to these registrars. TWC (Transaction Without Card) is something banks lose billions of USD every year on. In most cases though, they are able to respond accordingly and then the registrar (not the victim user or the bank) are the ones losing money. Further action would mean further loss. Gadi.
Adrian
created domains and discriminate between the ones that were created for good and the ones created for ill. How would one do this?
A good start would be to forbid the delegation of newly-registered domains that have not yet been paid for.
I am not aware of any registrars that extend credit other than via credit cards. Registries all require prepayment from registrars. Is there some loophole I'm not aware of? Even domain tasting involves paying and then getting a refund. If you mean waiting long enough to see if the credit card bounces, that would be a swell idea but since it can often take more than six weeks for the cardholder to notice a bogus charge and complain, I suspect you'd see some pushback on a waiting period that long. R's, John
The only constant is the malicious domain name.
If we are able to take care of all the rest, and DNS becomes the one facet which can rewind the wheel, DNS is the problem.
You have just explained how DNS is *NOT* the problem. The only constant is the domain name. That is handled by domain name registries, not by the DNS. Since domain name registries are not a technical issue, there is no technical solution to the problem. I suggest that you would get further by working with (or suing) the domain name registries that allow these domain names to be so "constant".
Or we can look at it from a different perspective: Should bad guys be able to register thousands of domains with "amazon" and "paypal" in them every day?
In my opinion, yes. This gives the police something to subpoena from the registries to track down these people. If they were registering random words from the dictionary, the police would not know what records to subpoena. And if the registries disallowed applications with amazon and paypal in them, then the crooks would be using random words from the dictionary.
Should there be black hat malicious registrars around?
Yes. Again it gives a target for the police. As the FBI learned in the 1950's, you get much further by chasing the money than by chasing the men behaving badly. --Michael Dillon
On Sat, 31 Mar 2007, Mikael Abrahamsson wrote:
On Sat, 31 Mar 2007, Gadi Evron wrote:
In this case, we speak of a problem with DNS, not sendmail, and not bind.
The argument can be made that you're trying to solve a windows-problem by implementing blocking in DNS.
Next step would be to ask all access providers to block outgoing UDP/53 so people can't use open resolvers or machines set up to act as resolvers for certain DNS information that the botnets need, as per the same analysis that blocking TCP/25 stops spam.
So what you're trying to do is a pure stop-gap measure that won't scale in the long run. Fix the real problem instead of trying to bandaid the symptoms.
IMHO, Windows will always have some 0-day appearing every quarter - whether it be in XP or Vista. Or it will be in Apache, or it will be in Sendmail or it will be in some other app. So if taking a 10,000 foot view, apps will always have 0-day holes that are abused. Nowadays, the latest vector is fast-flux. I think that closing that vector via fast closure of a particular domain name is something we should tackle. True, the baddies will find some other vector. But that doesn't mean we should ignore this one. -Hank
-- Mikael Abrahamsson email: swmike@swm.pp.se
... Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind.
As to blacklisting, it's not my favorite solution but rather a limited alternative I also saw you mention on occasion. What alternatives do you offer which we can use today?
on any given day, there's always something broken somewhere. in dns, there's always something broken everywhere. since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often. in practical terms, and i've said this to you before, you'll get as much traction by getting people to switch from windows to linux as you'd get by trying to poison dns. that is, neither solution would be anything close to universal. that rules it out as an "alternative we can use today". but, isp's responsible for large broadband populations could do this in their recursion farms, and no doubt they will contact their dns vendors to find a way. BIND9, sadly, does not make this easy. i'll make sure that poison at scale makes the BIND10 feature list, since clustering is already coming. at the other end, authority servers which means registries and registrars ought, as you've oft said, be more responsible about ripping down domains used by bad people. whether phish, malware, whatever. what we need is some kind of public shaming mechanism, a registrar wall of sheep if you will, to put some business pressure on the companies who enable this kind of evil. fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
On Mar 31, 2007, at 9:20 AM, Paul Vixie wrote:
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
Some SPs are doing DNS manipulation/poisoning now for various reasons, with varying degrees of utility/annoyance. If those SPs choose to manipulate their own DNS in a way which affects their own users, that's fine; if the users don't like it, they can to elsewhere. Some enterprises are doing the same kinds of things, with the same options available to the user population (though not always quite as easy to 'go elsewhere', heh). What SPs or enterprises choose to do for/to their own user bases is between them and their users. When we start talking about involving registries, etc., that's when we've clearly jumped the shark. There is no 'emergency', any more than there was an 'emergency' last week or the week before or the month before that - after a while, a state of 'emergency' becomes the norm, and thus the bar is raised. It's merely business as usual, and no extraordinary measures are required. Yes, there are ongoing, long-term problems, but they need rationally-thought-out, long-term solutions. 'Think globally, act locally' seems a good principle to keep in mind, along with 'Be liberal in what you accept, and conservative in what you send'. Much unnecessary grief and gnashing of teeth would be avoided if folks worries about what was going on in their own networks vs. grandiose, 'fix-the-Internet'-type 'solutions' (the appeal of the latter is that it requires no actual useful effort or sacrifice on one's own part, merely heated rhetoric and a pointed finger, which appeals to some of the least attractive aspects of human nature). ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo
On Sat, 31 Mar 2007, Roland Dobbins wrote:
week or the week before or the month before that - after a while, a state of 'emergency' becomes the norm, and thus the bar is raised.
Indeed. This background noise is what it means to "lose the war", we lost it, now we fight to maintain life in that hostile environment. Everyone, you, me and the cat next door are entitled to their opinions, but it is time for doing. Gadi.
* Paul Vixie:
since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often.
Well, once more people learn about DLV (especially the NS override extension that has been requested by zone operators), more and more questions will pop up why we can't do this for NS records they don't like for some reason. The genie is out of the bottle, I'm afraid.
in practical terms, and i've said this to you before, you'll get as much traction by getting people to switch from windows to linux as you'd get by trying to poison dns. that is, neither solution would be anything close to universal. that rules it out as an "alternative we can use today".
The legal details for operating and using a lookaside zone are rather interesting, which strongly suggests that this isn't a solution that can be rolled out in a reasonable time frame. On the more technical side, some very large operators have mostly out-sourced their DNS operation, so they can't easily deploy an upgrade from ISC even if it were available today.
at the other end, authority servers which means registries and registrars ought, as you've oft said, be more responsible about ripping down domains used by bad people. whether phish, malware, whatever. what we need is some kind of public shaming mechanism, a registrar wall of sheep if you will, to put some business pressure on the companies who enable this kind of evil.
I fear that many registrars make most of their money with trademark violations of their customers. If that is indeed true, showing any sign of responsibility could be suicidal.
since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often.
Well, once more people learn about DLV (especially the NS override extension that has been requested by zone operators), more and more questions will pop up why we can't do this for NS records they don't like for some reason. The genie is out of the bottle, I'm afraid.
i'm going to fwd this to dns-operations@lists.oarci.net and answer it there, since this is now far afield of "can i type that into an IOS prompt?".
On Sat, 31 Mar 2007, Paul Vixie wrote:
... Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind.
As to blacklisting, it's not my favorite solution but rather a limited alternative I also saw you mention on occasion. What alternatives do you offer which we can use today?
on any given day, there's always something broken somewhere.
in dns, there's always something broken everywhere.
since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often.
in practical terms, and i've said this to you before, you'll get as much traction by getting people to switch from windows to linux as you'd get by trying to poison dns. that is, neither solution would be anything close to universal. that rules it out as an "alternative we can use today".
but, isp's responsible for large broadband populations could do this in their recursion farms, and no doubt they will contact their dns vendors to find a way. BIND9, sadly, does not make this easy. i'll make sure that poison at scale makes the BIND10 feature list, since clustering is already coming.
at the other end, authority servers which means registries and registrars ought, as you've oft said, be more responsible about ripping down domains used by bad people. whether phish, malware, whatever. what we need is some kind of public shaming mechanism, a registrar wall of sheep if you will, to put some business pressure on the companies who enable this kind of evil.
I have done public shaming in the past, as you know. I'd rather avoid it if policy/technology can help out. Conversationally though, how would you suggest to proceed on that front?
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
Not for the bad guys, unfortunately. :/ Gadi.
at the other end, authority servers which means registries and registrars ought, as you've oft said, be more responsible about ripping down domains used by bad people. whether phish, malware, whatever. what we need is some kind of public shaming mechanism, a registrar wall of sheep if you will, to put some business pressure on the companies who enable this kind of evil.
I have done public shaming in the past, as you know. I'd rather avoid it if policy/technology can help out.
technology can help someone protect their own assets. policy can help other people protect their assets. public shaming can motivate other people protect their own assets. YMMV.
Conversationally though, how would you suggest to proceed on that front?
a push-pull. first, advance the current effort to get registrars and dynamic-dns providers to share information about bad CC#'s, bad customers, bad domains, whatever. arrange things so that a self-vetting society of both in-industry and ombudsmen have the communications fabric they need to behave responsibly. push hard on this, make sure everybody hears about it and that the newspapers are full of success stories about it. then, whenever there's a phish or malware domain whose dyndns provider or dns registrar is notified but takes no action, put it on the wall of shame. something akin to ROKSO would work. (in fact, spamhaus could *do* this.) make sure that the lack of responsible takedown is a matter of public record and that a sustained pattern of such irresponsibility is always objectively verifiable by independent observers who can each make independent judgements.
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
Not for the bad guys, unfortunately. :/
by "this kind of poison" i meant something that would be used by good guys to "whiteout" the domains needed/used by bad guys. it'll be inauthentic data, and if dnssec is ever launched, this kind of data will be transparently obviously inauthentic, and will just not be seen by the client population. so, yes, dnssec will end up helping the bad guys in that particular way.
On Sat, 31 Mar 2007, Paul Vixie wrote:
at the other end, authority servers which means registries and registrars ought, as you've oft said, be more responsible about ripping down domains used by bad people. whether phish, malware, whatever. what we need is some kind of public shaming mechanism, a registrar wall of sheep if you will, to put some business pressure on the companies who enable this kind of evil.
I've posted here a few times about this, but... in almost all cases of domain names used in a bad way (in malware or to further malware's intents) the domain is purchased on a stolen CC. The registrar knows this most often with in days of the purchase, they don't seem to turn off the domain though. Why is that? Why do they not terminate the domain or atleast terminate control of it by the 'bad actors'? It seems that if the registrars would terminate control in a timely fashion that would do what 'we' want, yes? remove the ease of use of this tool for the bad actors...
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since
if the local side of the problem (an enterprise let's say) wants to use the dns-tool in their toolbox, 'ok'. I'm not sure that at the provider level it's as simple as that since there is an aggregation of security policies there and often the policies conflict (you can look at xxx vs you can't look at xxx).
Summary: The US Department of Homeland Security (DHS) ... wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign. http://www.heise.de/english/newsticker/news/87655 -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey
Hi, On Apr 1, 2007, at 6:54 AM, J. Oquendo wrote:
Summary:
Confusion resulting from hearsay and extrapolations.
The "key-signing key" signs the zone key, which is held by VeriSign.
Except that the root zone hasn't been signed and there are no plans I am aware of do so (and I think I'd probably know). In one possible scenario, VeriSign would hold the zone signing key which would be signed by the key signing key. Who holds the KSK hasn't been established. However, in reality, nothing would change. Even if the root were to be signed, who signs it doesn't really matter -- the USG already must approve any changes made to the root zone. Rgds, -drc
On Sun, 1 Apr 2007, David Conrad wrote:
Hi,
On Apr 1, 2007, at 6:54 AM, J. Oquendo wrote:
Summary:
Confusion resulting from hearsay and extrapolations.
The "key-signing key" signs the zone key, which is held by VeriSign.
Except that the root zone hasn't been signed and there are no plans I am aware of do so (and I think I'd probably know). In one possible scenario, VeriSign would hold the zone signing key which would be signed by the key signing key. Who holds the KSK hasn't been established.
However, in reality, nothing would change. Even if the root were to be signed, who signs it doesn't really matter -- the USG already must approve any changes made to the root zone.
And of course, it can only approve "Willing changes".
Rgds, -drc
The US Department of Homeland Security (DHS) ... wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign.
Very interesting because it is the second story on the list this weekend which highlights that DNS domain registries (and ultimately the root zone) are a single point of failure on the Internet. Wouldn't the holder of these keys be the only ones able to spoof DNSSEC? And if the criminal community ever cracks DHS (through espionage or bribery) to acquire these keys, what would be the result. I just don't see how adding another single point of failure to the DNS system, in the form of a master key, helps to strengthen the DNS overall. It is probably time to start looking at alternative naming systems. For instance, we have a much better understanding of P2P technology these days and a P2P mesh could serve as the top level finder in a naming system rather than having a fixed set of roots. We have a better understanding of webs of trust that we could apply to such a mesh. Given that the existing DNS is built around two disctinct classes of IP address, i.e. stable ones that always lead to a root nameserver, and unstable ones which lead to other Internet hosts, could we not design a more flexible naming system around that concept? Could we not have more than 13 stable IP addresses in the net? Could we not leverage something like route servers in order to find the root of a local naming hierarchy? Now that well-educated and technically sophisticated criminal groups are attacking the DNS on multiple fronts, we need to be looking at alternatives to DNS for naming hosts. We need to get such alternative systems out into the wild where they can be tested. To date, we have seen some small amount of innovative thinking around DNS that has been tested. For instance, alternative roots which have failed in the wild and anycasting which has been a great success. But these things do not address the core technical problems of the whole DNS system. --Michael Dillon
On Mon, Apr 02, 2007 at 09:23:32AM +0100, michael.dillon@bt.com <michael.dillon@bt.com> wrote a message of 46 lines which said:
It is probably time to start looking at alternative naming systems. For instance, we have a much better understanding of P2P technology these days and a P2P mesh could serve as the top level finder in a naming system rather than having a fixed set of roots.
The only serious (?) proposal I've seen until now, CoDoNS (http://www.cs.cornell.edu/people/egs/beehive/codons.php), uses DNSSEC, so it has the same dependency on the US government.
better understanding of webs of trust that we could apply to such a mesh.
You mix up *resolution* of names (which could be done by a P2P mesh like CoDoNS, replacing the root name servers) and *registration* of names, which have to be hierarchical if you want to preserve unicity of names. And this is the important point of control (the root name servers are not controlled by the US government, unlike the registration root). So, you've not solved the problem.
It is probably time to start looking at alternative naming systems. For instance, we have a much better understanding of P2P technology these days and a P2P mesh could serve as the top level finder in a naming system rather than having a fixed set of roots.
The only serious (?) proposal I've seen until now, CoDoNS (http://www.cs.cornell.edu/people/egs/beehive/codons.php), uses DNSSEC, so it has the same dependency on the US government.
My message was not an encoded support message for any specific product or implementation. If anything, it was a call for research help. I realize is not a short term fix, but a problem like this needs to be attacked on many fronts at once.
better understanding of webs of trust that we could apply to such a mesh.
You mix up *resolution* of names (which could be done by a P2P mesh like CoDoNS, replacing the root name servers) and *registration* of names, which have to be hierarchical if you want to preserve unicity of names. And this is the important point of control (the root name servers are not controlled by the US government, unlike the registration root).
If there is a P2P mesh holding pointers to servers which provide namespace resolution, then you have a trust issue. How do you know that you can trust the part of the P2P mesh that you are talking to? How do the mesh members trust each other? This is where the web-of-trust approach is useful. Once such a mesh is in place, you no longer need the root of the hierarchy to be rigidly controlled by a single entity. It could be managed by some sort of confederation, rather like IP addressing is controlled by the RIRs, IANA and the NRO. It is the rigid control of the root if the naming hierarchy that leads to the single point of failure issue. And in fact, unicity of names is an illusion. It certainly does not exist in the real world and it does not exist in DNS unless you take an extremely narrow technical view. For instance, what about all those tasting domains that contain amazon or ebay in the name? Or in Russia where Cyrillic domain names are sometimes transliterated to ASCII characters using a French-based system (e.g. Iouri) or transliterated to ASCII using and English-based system (e.g. Yuri) or translated to English (e.g. George). But in the .ru registry, three independent entities could register iouri.ru, yuri.ru, and george.ru. Not to mention the fact that Russian domain names are often printed as .py in advertising which happens to be the TLD for Paraguay.
So, you've not solved the problem.
I never claimed to have solved any problem. In fact, I think my message was more a statement of requirements than a solution. If the researchers manage to come up with a workable system for multiple namespaces as a result, then so much the better. DNS may not be forever. --Michael Dillon.
On Mon, Apr 02, 2007 at 12:23:43PM +0100, michael.dillon@bt.com <michael.dillon@bt.com> wrote a message of 58 lines which said:
[unicity of names] does not exist in DNS unless you take an extremely narrow technical view.
I thought that NANOG was for extremely narrow technical discussions. For bold "We will replace the DNS and IP while we're at it" discussions, there are other forums :-)
[unicity of names] does not exist in DNS unless you take an extremely narrow technical view.
I thought that NANOG was for extremely narrow technical discussions. For bold "We will replace the DNS and IP while we're at it" discussions, there are other forums :-)
Yes, I was suprised when you replied to that message. In any case, NANOG definitely *IS* the right place to discuss replacing IP, although I don't expect much discussion until there is more IPv6 implementation in the USA. And I never proposed replacing DNS and IP at the same time. One transition at a time is enough to deal with. As for "other forums", your claim would be more credible if you would identify these other forums. As far as I know there is not currently any forum that is seriously studying a replacement for the current DNS architecture. If I'm wrong, please provide details. -- Michael Dillon
The Racines Libres have failed? There are so many out there that we cannot count them any longer. I think the only failure is the "single point of failure root". They have failed to be trustworthy. It is so easy, get a copy of a trustworthy root-zone and run your own root. From time to time compare your root to the others and fix any diffs. Better take the authoritative servers and fix your root-zone. I have never seen a personal root-server attacked. The single point of failure root gets attacked once per hour, because every hour it is 8 o'clock in the morning on some place and all those windows boxes get switched on. Cheers Peter and Karin Dambier michael.dillon@bt.com wrote:
The US Department of Homeland Security (DHS) ... wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign.
Very interesting because it is the second story on the list this weekend which highlights that DNS domain registries (and ultimately the root zone) are a single point of failure on the Internet. Wouldn't the holder of these keys be the only ones able to spoof DNSSEC? And if the criminal community ever cracks DHS (through espionage or bribery) to acquire these keys, what would be the result.
I just don't see how adding another single point of failure to the DNS system, in the form of a master key, helps to strengthen the DNS overall. It is probably time to start looking at alternative naming systems. For instance, we have a much better understanding of P2P technology these days and a P2P mesh could serve as the top level finder in a naming system rather than having a fixed set of roots. We have a better understanding of webs of trust that we could apply to such a mesh.
Given that the existing DNS is built around two disctinct classes of IP address, i.e. stable ones that always lead to a root nameserver, and unstable ones which lead to other Internet hosts, could we not design a more flexible naming system around that concept? Could we not have more than 13 stable IP addresses in the net? Could we not leverage something like route servers in order to find the root of a local naming hierarchy?
Now that well-educated and technically sophisticated criminal groups are attacking the DNS on multiple fronts, we need to be looking at alternatives to DNS for naming hosts. We need to get such alternative systems out into the wild where they can be tested. To date, we have seen some small amount of innovative thinking around DNS that has been tested. For instance, alternative roots which have failed in the wild and anycasting which has been a great success. But these things do not address the core technical problems of the whole DNS system.
--Michael Dillon
-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
On Mon, Apr 02, 2007 at 01:09:48PM +0200, Peter Dambier <peter@peter-dambier.de> wrote a message of 85 lines which said:
The Racines Libres have failed?
There are so many out there that we cannot count them any longer.
That's true. Dozens of first-year CS students have set up one and then tried to impress a girlfriend by claiming "I am now independant from the Evil ICANN".
I have never seen a personal root-server attacked.
I can attack yours, if you want more credibility.
michael.dillon@bt.com wrote:
Very interesting because it is the second story on the list this weekend which highlights that DNS domain registries (and ultimately the root zone) are a single point of failure on the Internet. Wouldn't the holder of these keys be the only ones able to spoof DNSSEC? And if the criminal community ever cracks DHS (through espionage or bribery) to acquire these keys, what would be the result.
A single bodied government which holds the keys to this is quite possibly a bigger problem than what we currently have. Way too much censorship if you ask me. Not to get super political here, but there is far too much going as it is concerning what can be said, shown, viewed by too many organizations in power as is.
Given that the existing DNS is built around two disctinct classes of IP address, i.e. stable ones that always lead to a root nameserver, and unstable ones which lead to other Internet hosts, could we not design a more flexible naming system around that concept? Could we not have more than 13 stable IP addresses in the net? Could we not leverage something like route servers in order to find the root of a local naming hierarchy?
Problems I can see with this would be when someone on the P2P begins injecting false data into a stream. How would the mesh be structured so as to avoid this. Perhaps using the same methods as ICANN, or NANOG, a group of say 50 companies can be designated the task of maintaining root servers on a revolving basis. The server could be configured in secure fashion (whatever this means nowadays) with maybe checksums and pass off the information to one another. E.g.: Verified Lookup User --> whois something.com --> nameserver1 nameserver1 --> I see something.com at 11.11.11.11 --> nameserver2 nameserver1 --> where do you see it nameserver2 nameserver2 --> I see it at 11.11.11.11 --> nameserver1 nameserver1 --> something.com is at 11.11.11.11 --> User Problematic Lookup User --> whois something.com --> nameserver1 nameserver1 --> I see something.com at 11.11.11.11 --> nameserver2 nameserver1 --> where do you see it nameserver2 nameserver2 --> I see it at 22.11.11.11 --> nameserver1 nameserver2 --> where DO YOU SEE something.com --> nameserver3 nameserver3 --> something.com is at 11.11.11.11 --> nameserver1 nameserver1 --> After double checking go to 11.11.11.11 --> user Creating entries: nameserver1: something.com is at 11.11.11.11 let's create a hash # sample hashing using md5 and sha $ echo "something.com 11.11.11.11"|shasum 8cb7294f15be3f5b95d24f0e9bf77a57d95345fb $ echo "something.com 11.11.11.11"|md5 c48af0b24a9014ccdce8b1233ffbb052 Both combined: 8cb7294f15be3f5b95d24f0e9bf77a57d95345fbc48af0b24a9014ccdce8b1233ffbb052 Enforced Lookup: User --> whois something.com --> nameserver1 nameserver1 --> Let me check my entry... nameserver1 --> 8cb7294f15be3f5b95d24f0e9bf77a57d95345fbc48af0b24a9014ccdce8b1233ffbb052 nameserver1 --> After checking go to 11.11.11.11 --> user Re-enforced Lookup: User --> whois something.com --> nameserver1 nameserver1 --> Let me check my entry... nameserver1 --> 8cb7294f15be3f5b95d24f0e9bf77a57d95345fbc48af0b24a90XXXXXXXXXXXXXXXXXXXX nameserver1 --> Not what I have. What do you see --> namerserver2 nameserver2 --> 8cb7294f15be3f5b95d24f0e9bf77a57d95345fbc48af0b24a9014ccdce8b1233ffbb052 nameserver2 --> Something fishy there --> nameserver1 nameserver1 --> Unresolved domain --> User Any nameserver can now compare that kind of hash before it sends out replies. If the hash matches, it's legit, if not, obviously there's a problem. What I can see happening with something like this would be DNS administrators having to recalculate hashes whenever they renumber one of their machines. Something like this would also deter "criminal gangs" from fiddling with DNS since it would likely be too difficult to counter. Hijackings could possibly cease, as well as the possibility of reducing malware if done correctly. My guess is load balancing, round robin DNS, etc., could affect this, but I'm sure other engineers here can figure out something better than allowing any government from intervening and trying to maintain what's perhaps one of the most fragile functions on the Internet. Maybe even multiple checksums for sites doing above-mentioned (load balancing, etc.) -- ==================================================== J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 sil . infiltrated @ net http://www.infiltrated.net The happiness of society is the end of government. John Adams
Problems I can see with this would be when someone on the P2P begins injecting false data into a stream. How would the mesh be structured so as to avoid this.
There is a lot of literature about P2P networking in its many variations. The nice thing is that it is mostly freely available on the net, unlike in some other scientific disciplines where more and more research is locked away behind electronic journal providers which charge atrociously high rates for a single article. Some Google searches to get started: p2p small-world pdf p2p chord pdf p2p kademlia pdf p2p dht pdf p2psim Chances are, that one of the more mathematically oriented researchers looking at graph theory and distributed hash tables, has already solved the problem. All you have to do is find it and apply it to a root replacement for a naming service hierarchy. --Michael Dillon
All, this was inaccurate reporting and no organizational entity has been specified to be the "master key" signer. There has been much discussion about moving DNSsec forward by our S&T folks to increase the level of security provided but we've been very much a facilitating role through S&T's work in this space. If Doug is lurking out there he can provide much more info or insight into this. Jerry ----- Original Message ----- From: <michael.dillon@bt.com> To: <nanog@merit.edu> Sent: Monday, April 02, 2007 4:23 AM Subject: RE: America takes over DNS
The US Department of Homeland Security (DHS) ... wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign.
Very interesting because it is the second story on the list this weekend which highlights that DNS domain registries (and ultimately the root zone) are a single point of failure on the Internet. Wouldn't the holder of these keys be the only ones able to spoof DNSSEC? And if the criminal community ever cracks DHS (through espionage or bribery) to acquire these keys, what would be the result. I just don't see how adding another single point of failure to the DNS system, in the form of a master key, helps to strengthen the DNS overall. It is probably time to start looking at alternative naming systems. For instance, we have a much better understanding of P2P technology these days and a P2P mesh could serve as the top level finder in a naming system rather than having a fixed set of roots. We have a better understanding of webs of trust that we could apply to such a mesh. Given that the existing DNS is built around two disctinct classes of IP address, i.e. stable ones that always lead to a root nameserver, and unstable ones which lead to other Internet hosts, could we not design a more flexible naming system around that concept? Could we not have more than 13 stable IP addresses in the net? Could we not leverage something like route servers in order to find the root of a local naming hierarchy? Now that well-educated and technically sophisticated criminal groups are attacking the DNS on multiple fronts, we need to be looking at alternatives to DNS for naming hosts. We need to get such alternative systems out into the wild where they can be tested. To date, we have seen some small amount of innovative thinking around DNS that has been tested. For instance, alternative roots which have failed in the wild and anycasting which has been a great success. But these things do not address the core technical problems of the whole DNS system. --Michael Dillon
Hi,
Wouldn't the holder of these keys be the only ones able to spoof DNSSEC?
Yes. This is an assumption of DNSSEC, regardless of who signs the root. The implication of this (and the fact that emergency key rollover requires everyone on the planet with a validating resolver to update the root trust key manually) is that protecting the root key signing key is a bit important. Rgds, -drc
On Mon, Apr 02, 2007 at 07:45:08AM -0700, David Conrad wrote:
Hi,
Wouldn't the holder of these keys be the only ones able to spoof DNSSEC?
Yes. This is an assumption of DNSSEC, regardless of who signs the root. The implication of this (and the fact that emergency key rollover requires everyone on the planet with a validating resolver to update the root trust key manually) is that protecting the root key signing key is a bit important.
Rgds, -drc
one important attribute of key roll would seem to be the lack of a "flag-day". ... there are at least a couple of proposals that mitigate that particular risk. --bill
Paul Vixie wrote:
on any given day, there's always something broken somewhere.
in dns, there's always something broken everywhere.
The catch-phrases you come up with are delightful. Catchy and deeply useful. Would that more folk would take them to heart, for their implications.
since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often.
Although there are times to consider pursuing an ugly-but-expeditious path, you've made the point that the effects are long-term, while the symptoms might only be short-term. Given the complexity of the abuse space, it's worth thinking in terms of basic benefit in the change, while using the immediate situation merely as a motivator: Is the change something that makes sense on its own, independent of the current abuse manifestation? If so, then go ahead and do it. If not, the odds are high that it will only be part of a process of adding warts to warts.
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
I was sitting at a bar, one Saturday, many years ago. Behind the bartender was a sign that said "Free beer tomorrow". We were in an alcohol-paranoid state, so I asked the bartender about the sign, since I knew they'd be closed on Sunday. His comment was that tomorrow never comes. Someday, indeed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Paul Vixie wrote:
... Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind.
As to blacklisting, it's not my favorite solution but rather a limited alternative I also saw you mention on occasion. What alternatives do you offer which we can use today?
on any given day, there's always something broken somewhere.
in dns, there's always something broken everywhere.
since malware isn't breaking dns, and since dns not a vector per se, the idea of changing dns in any way to try to control malware strikes me as a way to get dns to be broken in more places more often.
I'd say it's a way to get DNS to be more inconsistent and it's likely to happen. Broken is both in the eye of the beholder and in the eye of the end-user.
but, isp's responsible for large broadband populations could do this in their recursion farms
That's right. And it will perpetuate the arms race of whitehats vs. blackhats. But that's no reason not to add intelligence into the DNS -- either in-band or out-of-band. Most of us already do some level of DNS intelligence out-of-band (passive dns, uribls, etc) and the power of doing it in-band is a logical next step.
fundamentally, this isn't a dns technical problem, and using dns technology to solve it will either not work or set a dangerous precedent. and since the data is authentic, some day, dnssec will make this kind of poison impossible.
Unfortunately, that day, if it ever comes, will come after bot herders stop using DNS to manage their botnets because other mitigation strategies will have already forced them to move on. -David
On Sat, 31 Mar 2007, Gadi Evron wrote:
Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind.
Your reality must be interesting. In my reality, the problem is with a client app thats historically exhibited this exact same sort of "0day" "internet destroying" flaw about once a month. --matt@snark.net------------------------------------------<darwin>< Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
On Sat, 31 Mar 2007, Matt Ghali wrote:
On Sat, 31 Mar 2007, Gadi Evron wrote:
Back to reality and 2007: In this case, we speak of a problem with DNS, not sendmail, and not bind.
Your reality must be interesting. In my reality, the problem is with a client app thats historically exhibited this exact same sort of "0day" "internet destroying" flaw about once a month.
Is that the web app that registers domains and controls name servers at registrars or the massive DDoS and fraud we see running DNS as it's own house? Gadi.
Paul Vixie wrote:
whoa. this is like deja vu all over again. when barb@CERT asked me to patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host names in order to protect sendmail from a /var/spool/mqueue/qf* formatting vulnerability, i was fresh off the boat and did as i was asked. a dozen years later i find that that bug in sendmail is long gone, but the pain from BIND's "check-names" logic is still with us. i did the wrong thing and i should have said "just fix sendmail, i don't care how much easier it would be to patch libc, that's just wrong."
are we really going to stop malware by blackholing its domain names? if so then i've got some phone calls to make.
Okay, what I am about to suggest here is clearly going to be heretical, and I have to admit I thought about it before reading Paul's post... but I still want to put it out for thought. Clearly, the bad guys are manipulating DNS as a means to hide. Quoting Gadi from earlier: "Every day we see two types of fast-flux attacks: 1. Those that keep changing A records by using a very low TTL. 2. Those that keep changing NS records, pretty much the same." So, since they are manipulating DNS, how about trying to "fix" DNS as somewhat of a work-around here? After all, this is a DNS issue, and **MAYBE** a patch to BIND may be the easiest temporary work-around? What I would suggest is as follows: Add an option to BIND that: a) Returns a lookup failure if the TTL for the NS or A record is "too low" b) Caches the failure record for the server's "negative lookup" TTL time period to slow the rate of future lookups c) Clearly flags the forced failure in the query log to allow for the identification of potentially infected hosts and to help evaluate the effectiveness of this kludge There should probably be separate options for setting minimum acceptable NS and A TTLs. I would think that in most circumstances you would want to consider rejecting NS RRs with TTLs < 4hrs and A RRs with TTL < 1hr. If my bit-herding skills were a little more up to date, I might have even tried to write such a patch myself. I think we can all agree that this is a "BAD IDEA", but given the current circumstances, maybe this bad idea could be the lesser of several evils? Maybe we could get an "unofficial" patch from someone outside the ISC to allow this idea to be tried, thus avoiding ISC's having to forever support another bad idea that in reality didn't fix much? I would posit that if we don't try it, we would never know how effective it would be. Jon -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
* Fergie:
While the 0-day exploit is the ANI vulnerability, there are many, many compromised websites (remember the MiamiDolhins.com embedded javascript iframe redirect?) that are using similar embedded .js redirects to malware hosted sites which fancy this exploit.
And some of them have vast audiences, increasing the potential for a major "issue" -- TBD.
In today's world of ubiquitous advertising, vast audiences equal lots of money. That's why this is a problem which a few class-action suits can and will fix. The hard problem is repeated damage done by many small incidents.
participants (45)
-
Adrian Chadd -
Alexander Harrowell -
Andre Oppermann -
Andy Davidson -
bmanning＠karoshi.com -
Chris L. Morrow -
Chris Owen -
Dave Crocker -
David Conrad -
David Ulevitch -
Donald Stahl -
Douglas Otis -
Fergie -
Florian Weimer -
Frank Bulk -
Gadi Evron -
Geo. -
Hank Nussbacher -
J. Oquendo -
Jerry Dixon -
Joe Greco -
John Levine -
Jon R. Kibler -
Ken Simpson -
Kradorex Xeron -
Lasher, Donn -
Mark Green
-
Matt Ghali -
Matthew Crocker -
Mattias Ahnberg -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Patrick Giagnocavo -
Paul Vixie -
Paul Vixie -
Peter Dambier -
Petri Helenius -
Randy Bush -
Roland Dobbins -
Simon Waters -
Stephane Bortzmeyer -
Stephen Satchell -
Suresh Ramasubramanian -
Thomas Leavitt -
Tony Finch