On-going Internet Emergency and Domain Names

Mailman List Mirror (Read Only)
21

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

22

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.)

23

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

24

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

25

* 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.

26

* 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.

27

>
> 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

28

> 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?".

29

Gadi Evron wrote:
> The real problem? Okay, I'd like your ideas than. :slight_smile:

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.

30

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?

31

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

32

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

33

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

34

Douglas Otis 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.

35

> ...
> 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. :confused:

  Gadi.

36

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.

37

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.

38

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.

39

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

40

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.