On another security note... (of sorts)

<upcoming-getting-old-birthday-ramble>

While on another list (security list that some of you guys are on) there
is a discussion about a particular botnet that the "BP approach" of
containment is occurring. Not a big deal, we've all seen them from time
to time.

I read with interest on how volunteers are scrambling to contain this
botnet. Mind you, most of us work and do this (security tidbits) at the
same time while we work. Many of us do it for self-satisfaction, for
learning, for maybe naively thinking we can help make the net a better
place (INSERT_SAPPY_SONG_THERE). I just can't help but taking the 50k
foot view here... Why is it that network operators can't work together
on instances like this and have a "botnet killswitch" framework in
order. Now I know I will see the ramblings of "Why should I waste my
time (spend my money)" or "This is not an operational post take a hike"
and other similar posting however, this IS related to 'many-a-networks'
that could be avoided.

RFP anyone.. Botnet Mitigation for Networks surely collectively it would
and CAN work. Is it going to take an act of someone 'pwning' everyone's
account here before someone else says: "We should work together" or will
go in one ear and out the other while misfits run around emptying out
accounts, causing businesses to go under. Some of you guys have the most
amazing minds and have literally been the glue for what we use (the
Internet) and some have been the laziest admins I've seen on the planet.
Surely even a minimal framework to submit "validated" botnet
distribution sites is something everyone can collectively do. Nipping at
the head surely minimizes the overall damage these things are doing.

Now I do know some would come back and state the oft-said "Why bother!
... Dude fast-flux, etc." We know... To those, why respond. How about
solutions from those who are controlling how traffic on the net flows.

</upcoming-getting-old-birthday-ramble>

A nice idea, but consider if a more automated tool/system was created to
behead a botnet (50,000 null0 routes to blackhole all the nodes? Or accept
collateral damage? etc). Now consider that jujutsu is designed around using
the opponent's energy against him.

How can this possibly go wrong? :slight_smile:

Hint: Why do many sites refuse to accept automated BGP feeds from Cymru's
bogon list or RIR services?

The same reason many sites don't follow best practices and let spoofed
packets leave their network, etc?

Why is it that network operators can't work together
on instances like this and have a "botnet killswitch"

Trust (or lack thereof).

Cheers,

Michael Holstein
Cleveland State University

Why is it that network operators can't work together
on instances like this and have a "botnet killswitch"

Trust (or lack thereof).

If networking tools were designed properly it wouldn't matter...

its about designing tools for the intentional creation of evidence and
rather than arguing with the suits about what is necessary just make
them create a list of evidence aspects and then we implement that.

This isnt complex its about building systems which are better (more
trustworthy) than their operators.

Just my two cents.

Todd Glassey

Damned if they do, Damned if they don't.

It seems like every 4-6 weeks people alternate between ISPs are bad because they don't try to prevent X, Y or Z; and then 4-6 weeks later
ISPs are bad because they tried to prevent A, B or C. It doesn't matter
what A, B, C or X, Y, Z are; it must be the ISPs fault.

Everyone agrees that ISPs are bad, they just disagree about what ISPs
are supposed to do about whatever.

And so it goes...

Sean Donelan wrote:

Damned if they do, Damned if they don't.

It seems like every 4-6 weeks people alternate between ISPs are bad
because they don't try to prevent X, Y or Z; and then 4-6 weeks later
ISPs are bad because they tried to prevent A, B or C. It doesn't matter
what A, B, C or X, Y, Z are; it must be the ISPs fault.

Everyone agrees that ISPs are bad, they just disagree about what ISPs
are supposed to do about whatever.

And so it goes...

Odd, I definitely don't recall saying outright ISP's are bad. More to
the tune of "ISP's can do more given they're in the best position to do
so..." which brings things full-circle, what can be done? How about an
RFC, then building from there. Anyone can comment about the potential of
"I'm not adding hundreds of thousands of null0's to my Cisco!@" and the
point would be missed. As an NSP/NAP/ISP (pick your poison), you have
the potential to see where your machines are connecting to. And I don't
mean snooping their traffic outright, but its as simple as keeping tabs
on a "destination", if you KNOW and it has been CONFIRMED, that the
destination is a known purveyor "of un-fine" goods, wouldn't you like to
potentially help your clients before they become zombiefied?

If there was a method for operators to obtain information and share it,
(think an unbiased, validated, "most wanted" list) do you really want to
state that you wouldn't care about it, you couldn't use it. Surely I'd
like to use something similar and if I were in a position to do
something on a massive scale to eliminate bad traffic from 1) reaching
my customers (since money is obvious the main concern) and 2) from
making sure my customers don't affect your customers (YOUR money), I
would jump up and down on it doing whatever I could.

So it's not the ISP's are bad (at least to me they're not), it's more
like "ISP OPERATORS/OWNERS are too busy fighting AGAINST things like
this from happening, often spending more time and effort against it,
then they are trying to collaboratively solve a problem."

Analogy: "ALL gunmakers have seen their firearms mistakenly fire off at
will (purposefully or accidentally). They all agree that by putting a
safety mechanism, the rates of fatalities and injuries will go down.
Some choose not to, because after all, they would need to spend more
money to do so... Many protest against it: Smith and Wesson doesn't have
that, why should I?!... Fatalities continue and gunmakers complain: All
gunmakers are bad right, sure... uh-huh"

What's wrong with that analogy. What about responsibility. Forget the
politricks for a moment and think about the *ultimate* bottom line
here... Would you like to prevent someone from possibly wrecking havoc
on your personal bank account? Remember, what goes around comes around.
You're not only doing neighbors (peers) a favor but if collectively the
same approach was taken by many, there would be less "dirty traffic"
around. No one on this list can seriously counter this claim. We can get
into: "oh yea smart ass... They could encrypt!@... They could fast
flux!!!, they could..." Guess what? What is anyone going to do when they
can't connect?

E.g:
src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net)
My_NSP(hourly) ---> Mega_Peer_Dirty_Host_Watcher --> get_list_apply_filter

Result:

src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) -->
My_Provider --> ::1

Anyway, just a thought, maybe a far out there thought, but I truly
believe it can be done at an upstream level with little to no cost. I
believe it costs more to sit around complaining and doing nothing than
it does when you start losing customers because someone compromised them
and wiped out their accounts driving them to bankruptcy.
(N.Y. Firm Faces Bankruptcy from $164,000 E-Banking Loss – Krebs on Security)

That's certainly one of the biggest non-technical reasons. Others go by the acronyms NIH and NIMBY.

But to me it boils down to some hard questions: what is a botnet, who gets to make that definition, what is a killswitch, and who is allowed to push it?

I'm sure the collective wisdom here is capable of pulling the task off at least in theory; the hard part would be deciding whether to do it in hardware or software....

I'm sure the collective wisdom here is capable of pulling the task off at least in theory;

The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined), skillset shortages/concerns (very real), customer perception concerns (both real and imagined), and so forth.

The second tier of barriers are those surrounding trust. It's basically a sociological analogue of 'the PKI problem'.

Technology issues form the third set of barriers. Yes, they're real and they're important, but if we could wiggle our noses a la Elizabeth Montgomery and make all the technology issues go away, the other sets of issues would still preclude any kind of universal solution, for some value of 'solution'.

There's a great deal of opsec coordination and work which takes place in a sub rosa fashion, via individual actions, closed, vetted mitigation communities, ad hoc personal relationships, etc. In actuality, a very great deal of the useful opsec work that gets done is accomplished by folks who in some cases are going beyond their portfolios to do so, as their management, legal teams, PR/marketing teams, et. al. would actively forbid them to do this work, were they to know about it.

That's one of the reasons why a lot of people who make sweeping generalizations and recommendations about 'cyber-this' and 'cyber-that' tend not to have a good grasp of even the fundamentals - they aren't the folks who do the actual work, they don't know who does the actual work, and they often don't know anybody who knows somebody who actually does the actual work. They often don't even know that actual work is taking place, or what it entails, in the first place, because the actual work takes place out of the limelight.

the hard part would be deciding whether to do it in hardware or software....

;>

Dobbins, Roland wrote:

The thorniest issues aren't technology-related, per se; they're legal

exposure (both real and imagined), regulatory concerns (both real and
imagined), antitrust concerns (both real and imagined),
management/marketing/PR concerns (largely imagined), skillset
shortages/concerns (very real), customer perception concerns (both real
and imagined), and so forth.

Legal issues for a situation like this can easily be resolved however
the problem boils down to who is willing to become "case law." There
aren't many laws surrounding this topic. Antitrust and regulatory issues
too can be trumped when businesses collectively conclude that its for
the best interest of everyone. I believe that too many perceive this
imaginatory 'brick wall' coming down on them and often take a step back
choosing to do nothing then coming back and wondering why they're
businesses are now listed on DataLossDB.org.

Customer perceptions and concerns very real? I'm curious to know what
your perception is. As a customer *somewhere* down the line, if a
business slash vendor told me they were working with other businesses to
deter/minimize fraud, I'd be all for it. I can think of any situation
where I would come around to a grinding halt: E.g.: From Starbucks:
"We're working with SEARS to minimize theft/fraud..." me: "OMG No! You
better not work to make sure thieves don't get ahold of my data!" I
didn't follow that glaringly big "very real." If you mean on the bits
side of things... E.g. (myself working at an ITSP) My competitor: "We're
working to make an attacker database to defend ourselves from
toll-fraudsters, care to join?" ... Me: "No way in hell I'm going to
defend myself because you're seeing more attacks. Thanks but no thanks!"

Maybe naivete on my part, but I don't see how customers would have
issues if the scenario/framework was concisely explained.

The second tier of barriers are those surrounding trust. It's

basically a sociological analogue of 'the PKI problem'.

Anyone here not peering, raise your hand?! Sure there will be trust
issues, those too can be overcome. A "vetting" process could be
implemented and selected individuals can be "voted" in or out. We
"trust" NANOG to select the best individual to moderate this list. At
the granular level, I don't know anything about the moderator, yet I
trust my peers knew enough to give them a vote of confidence. Should I
go back and and create a dossier on the moderator or should I trust my
peers. I think for the most part it's a "so far so good" situation. Life
goes on until otherwise noted.

Technology issues form the third set of barriers. Yes, they're real

and they're important, but if we could wiggle our noses a la Elizabeth
Montgomery and make all the technology issues go away, the other sets of
issues would still preclude any kind of universal solution, for some
value of 'solution'.

Here is a semi-universal solution... Throw an N-Byte field into the TCP
protocol and label it "dirty" the dirty bit. The dirty bit would be for
a combination of a host and or other identifier which came into the
radar N amount of times. The dirty bit would automatically get populated
into every routing table X amount of time where if a "dirty bit" tried
to route traffic from ANYWHERE, after some time, even its own TCP stack
wouldn't let it route out.

Even the collaboration of about 12 major companies (MS, Cisco, Juniper,
Sun, IBM) would likely cut the likelihood of attacks to probably in the
teen percentile.

That's one of the reasons why a lot of people who make sweeping

generalizations and recommendations about 'cyber-this' and 'cyber-that'
tend not to have a good grasp of even the fundamentals - they aren't the
folks who do the actual work, they don't know who does the actual work,
and they often don't know anybody who knows somebody who actually does
the actual work. They often don't even know that actual work is taking
place, or what it entails, in the first place, because the actual work
takes place out of the limelight.

Acknowledged... Still I believe a framework
(anti-malicious/pattern-matching/dirty-host) is long overdue. I also
believe far too many people take the "NIMBY" approach and make excuses
as opposed to solutions. This is seriously evident based on the amount
of responses to something which is (I perceive to be) mission critical.
Moreso than arguing over the pros and cons of NOT doing anything.

<http://tools.ietf.org/html/rfc3514>

;>

I recommend kc.claffy's notes on the subject:

Ten Things the FCC Should Know about the Internet
http://www.caida.org/publications/presentations/2009/top_ten_fcc/top_ten_fcc.pdf

and

top ten things lawyers should know about the Internet
http://blog.caida.org/best_available_data/2008/04/16/top-ten-things-lawyers-should-know-about-internet-research-1/

Eric

It's one thing to be sitting in my office rationally discussing what my bank
does to prevent credit card fraud, and almost nobody will disagree with the
concept that the bank should try to prevent fraud. However...

It's quite another when I'm driving to my brother's funeral, stop to get gas in
the middle of the night. For some reason, they go ahead and pump the gas
before running the credit card, and after they've pumped nearly a full tank of
gase, my credit card is declined and flagged (I find out later) by my bank's
anti-fraud group because it's being used 3 states away from where it's usually
used. Since they don't take checks, I'm forced to use pretty much all the cash
I was planning to use for tolls/etc so I had to find a way to Long Island
without paying any tolls because the stupid card wasn't working in ATMs in the
area either. Driving around Trenton (where I've never been before) at 3AM
trying to find the construction detour from I-295 to Route 1 because my map
says that's my best free way to LI wasn't my idea of fun...

Fortunately for my sanity, I was able to get hold of them the next morning and
convinced them I was me by having them call me back on the phone number they
already had for me - if somebody in their fraud group had realized that if the
credit card was stolen, the cell phone might be as well, I'd have been
screwed...

Understand now how customers might have isssues?

... my credit card is declined and flagged (I find out later) by my bank's
anti-fraud group because it's being used 3 states away from where it's usually
used. ...

Or in my recent case, I used my card multiple times in California in April, and
the next time was trying to make a *deposit* back home in Michigan a month or so
later. Card rejected.

Fortunately for my sanity, I was able to get hold of them the next morning and
convinced them I was me by having them call me back on the phone number they
already had for me - if somebody in their fraud group had realized that if the
credit card was stolen, the cell phone might be as well, I'd have been
screwed...

Unfortunately, I had to go to a credit union branch, and have them call the
main office after showing my drivers license for picture proof.... And that
meant I had to wait 3 days for the office to be open after the holiday!

Understand now how customers might have isssues?

Yep, most simple algorithms are severely flawed. Doesn't mean there couldn't be
better algorithms. And an understanding that banking is just the same as a
grocery store or a mall -- or an ISP....