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> -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said:
RFP anyone.. Botnet Mitigation for Networks surely collectively it would and CAN work.
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? :) Hint: Why do many sites refuse to accept automated BGP feeds from Cymru's bogon list or RIR services?
On Thu, 15 Jul 2010, Valdis.Kletnieks@vt.edu wrote:
On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said:
RFP anyone.. Botnet Mitigation for Networks surely collectively it would and CAN work.
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? :)
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. (http://krebsonsecurity.com/2010/02/n-y-firm-faces-bankruptcy-from-164000-e-b...) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
On 7/15/2010 11:40 AM, Michael Holstein wrote:
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
Cheers,
Michael Holstein Cleveland State University
On Thursday, July 15, 2010 02:40:50 pm Michael Holstein wrote:
Why is it that network operators can't work together on instances like this and have a "botnet killswitch"
Trust (or lack thereof).
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....
On Jul 16, 2010, at 9:42 PM, Lamar Owen wrote:
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....
;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
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'.
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
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. 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. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
On Jul 19, 2010, at 8:06 PM, J. Oquendo wrote:
Here is a semi-universal solution... Throw an N-Byte field into the TCP protocol and label it "dirty" the dirty bit.
<http://tools.ietf.org/html/rfc3514> ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Mon, 19 Jul 2010 08:06:08 EDT, "J. Oquendo" said:
Maybe naivete on my part, but I don't see how customers would have issues if the scenario/framework was concisely explained.
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?
On 7/19/10 10:21 AM, Valdis.Kletnieks@vt.edu wrote:
... 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....
On 7/16/10 11:17 PM, 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. ...
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... and top ten things lawyers should know about the Internet http://blog.caida.org/best_available_data/2008/04/16/top-ten-things-lawyers-... Eric
participants (10)
-
Dobbins, Roland -
Eric Brunner-Williams -
J. Oquendo -
Kornelijus Survila -
Lamar Owen -
Michael Holstein -
Sean Donelan -
todd glassey -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson