[Dshield] Possible solution for ISP (was DShield's public goals)

Tom dshield at oitc.com
Wed Jan 18 21:24:24 GMT 2006


I must admit that I'm at a loss with this thread.

Why should Joe User (the know-nothing dialup guy that Valdis 
constantly wants to focus on) be given access to any port other than, 
for example, SMTP (to his isps mailserver only) HTTP, POP, IMAP and 
HTTPS?  Joe User doesn't even know how to use FTP much less SSH or 
anything else. If Joe User wasn't given the same access privileges 
that a sophisticated user is given, the whole problem would be self 
limiting.

Tom


At 1:04 PM -0600 1/18/06, Laura Vance wrote:
>Valdis.Kletnieks at vt.edu wrote:
>
>>On Tue, 17 Jan 2006 11:39:23 CST, Laura Vance said:
>>
>> 
>>
>>>The thing is, this idea could be free.  If someone hosted the
>>>computer(s) that would run the system, there is no other monetary cost
>>>to the ISP.  It's simply a web site that the sales department checks
>>>before they sign up a new customer.  It could be done at the same time
>>>they check the credit score of the customer... maybe even before to save
>>>the ISP some money on the credit check if the client is on the bad list
>>>at the moment.
>>>   
>>>
>>
>>It can be free, as long as Somebody Else pays for it.
>>
>>We have a cat, we have a bell - the solution is left as an exercise 
>>for the student ;)
>>
>> 
>>
>>>It would be easy enough to check to see if your competitor had signed
>>>up, because the list of participating ISPs could be generated in
>>>real-time.
>>>   
>>>
>>
>>No.  I'm talking *pre-deployment*.  You're NetZero.  EarthLink says "We're
>>investing $10M to deploy this, and we'll go live next July".  You then reply
>>"OK, We'll pony up *our* $10M to deploy, and we'll go live next August".
>>
>>Come June, you've spent $8M, and Earthlink says "Neener neener! Fooled you,
>>we didn't do anything about deploying. HAND."
>>
>> 
>>
>How much money does it cost to change a procedure?  Certainly not in the
>millions.  Make a correction sheet, make hundreds or thousands of
>copies, mail it to the branch offices and have them put it in the
>manual.  Conference call the managers or even use email and explain to
>them what the change is and why it's necessary.  How much would that
>cost?  I don't think that paper costs millions of dollars, I also don't
>think a conference call (or even many one on one calls) would cost
>millions, and if email were used it wouldn't cost anything above what
>the ISP already pays for their connections.
>
>The only real cost is the upkeep of the server, but how many ISPs have
>server farms already that are able to stay up with little human
>interaction?  This server wouldn't sit in any ISPs server room, so that
>no single ISP could hold the system hostage.  Yes, it would have to sit
>on a network somewhere, but even that cost wouldn't be anywhere near the
>millions.  There would be no hardware or software that the ISP would
>have to install.  The system would reside on a central server being
>backed up to one or more machines, it could even have backups on
>different networks across the Internet.
>
>Where are you getting those cost figures?  It seems like you don't
>really understand the type of system that I talked about, so maybe no
>matter how much I explain "low cost," you'll never see what I mean.
>
>>>Probably because that involves reprogramming possibly hundreds of
>>>routers... these man-hours could be avoided.  The disconnection (if that
>>>was determined to be what was used) could be done via the billing
>>>system.  ISPs can easily flip a switch in the software when you don't
>>>pay your bill.
>>>   
>>>
>>
>>So you're expecting the same Comcast that has no trouble finding users and
>>turning them off when they don't pay, and that should have *no* trouble
>>identifying their top 400 problem accounts (match Senderbase to TACACS/DHCP
>>logs and you're done) and turning them off, to do the *extra* work involved
>  >in deploying your scheme, when they don't already do what they 
>could easily do?
>>
>>Why should they start carrying their trash to the curb and tipping the
>  >garbageman besides, when they aren't carrying the trash to the curb now?
>>
>> 
>>
>The reason they aren't carrying the trash to the curb now is because it
>takes more effort to do so.  Currently, if they decide to turn off a
>subscriber for an infection, they now need to provide support to help
>fix that user's computer, because ISPs currently take responsibility for
>the machines in their client locations.  They don't take the trash to
>the curb, because right now if they take the trash to the curb, they
>also have to build the trash truck, drive the trash truck, run the
>landfill, and clean up everything when they're done.  What I've
>suggested will make it so all they have to do is take the trash to the
>curb and let someone else deal with the rest.  There is no extra work,
>because the responsibility for repairing a user's computer falls to the
>user and the company that they use to fix their machine.  The user pays
>for any repair costs.  The user does the leg work to make sure the
>repair company clears their name on the list.
>
>You could almost compare it to the insurance industry (yes, I know the
>comparison isn't 100%, it's just an example).  You drive along just
>fine, you get into an accident, you have to do what it takes to get your
>car in a working condition again, the Insurance company raises your
>rates if it was your fault, but you can take defensive driving to remove
>that extra surcharge.  There are so many industries that use similar
>principals.  Of course there are ways to commit fraud, but in the human
>world, nothing is fraud proof.  If we didn't do something because
>someone *could* fraudulently take advantage of it, then nothing would
>ever get done.... nobody would ever do anything.
>
>>>If they can get on the web, they would be able to participate too.  If
>>>the system were free, then it wouldn't be a cost issue.  If they don't
>>>participate and the policy is to block, then you block them.  Why would
>>>it make a difference that they are outside of the US?
>>>   
>>>
>>
>>Go ahead. Block all of China.  That will be nice, fast, cheap - and whether
>>you get it to stick will depend how many of your customers still have family
>>over there...
>>
>>Collateral Damage.  What happens to your bottom line when all the customers
>>that can't get where they want move to an ISP that *will* let them?
>>
>> 
>>
>All of China wouldn't be blocked.  Did you read the partial block
>option?  China would still be able to get to all business web sites and
>all ISP hosted web sites.  They would still be able to get to all of the
>search engines... they would still be able to use the Internet for all
>legitimate interaction.  The only thing that would be denied is for
>someone in China user-space to initiate a direct connection to someone
>in the participating ISPs user-space.  All other connections would be
>allowed just as they are now.  The NAT solution would do the exact same
>thing, but it would make it so that *nobody* at any ISP could make a
>direct connection to the user-space of any other ISP without massive
>labor to maintain ingress firewall IP/port forwarding rules.
>
>Again, how is this partial block as bad as anything else that has been
>suggested and _not_ attacked?  What is your position?  Would you prefer
>to leave things the way they are or block all ingress/egress traffic to
>specific ports?  What happens when the newest virus/botnet simply
>searches for an allowed port to connect to a central server that listens
>on all ports... would you block all ports?  How is that better than what
>I've suggested?  There is no solution that can be applied to everyone
>that will work for everyone.  Several people have made suggestions to
>provide for rule-based disconnects that software could handle, and those
>are much better than blocking everyone because some people don't know
>how to secure their computer.  Also, how is this any different than SBC
>blocking inbound traffic to their user-space from Comcast user-space?
>I've read on here many many times people say that ISPs should block all
>connection attempts from Comcast user space.  How is that better?  At
>least with my suggestion there is some discretion and a guideline for
>when to block user-space and when not to block user-space.  The key here
>is that currently, there is no provision for opening those blocks once
>they are in place.  My suggestion provides for re-allowing full user to
>user connection.
>
>>>>5) There's also a very real possibility that unless your scheme 
>>>>has some sort
>>>>of legislative backing, that a participating ISP could get sued 
>>>>into bankruptcy
>>>>by a non-participating competitor ISP for restraint-of-trade issues.
>>>>     
>>>>
>>
>> 
>>
>>>How would this be any different than Earthlink blocking all inbound port
>>>25 from NetZero's user IP space?
>>>   
>>>
>>
>>Paging Paul Vixie.. Paging Paul Vixie... ask Paul next time you see him just
>>how much in legal fees the MAPS project ran up, defending itself against
>>lawsuits from spammers, *and MAPS never actually blocked anybody*....
>>
>>"In a not-surprising turn of events, LazyISP sued the top 10 ISPs for
>>anti-trust restraint-of-trade violations today, based on their refusal to
>>deliver packets from LazyISP unless they joined in a 'non-mandatory' club..."
>>
>>Go take a look at the legal activity when Level3 depeered XO - and that
>>was *one* ISP telling another "We won't accept packets *directly*, you'll
>>have to send them the long way around".
>>
>> 
>>
>You are still basing this on the assumption that *all* traffic from the
>non-participating ISP will be denied to all computers on the
>participating ISP network.  It's only a block for participating
>user-space inbound from non-participating user-space.  Business web
>sites and machines would still be the way they are now.  Level3 denied
>*all* packets from XO, this is different.  The comparison you're making
>is invalid, because this is *not* a total block between ISPs.
>
>>>They do get a benefit before it's fully deployed, because another part
>>>of the idea is that they no longer have to provide tech support for
>>>non-connection issues.
>>>   
>>>
>>
>>No, they don't.  They can't use the "nuclear option" (block all packets from
>>a non-participating ISP) until 97 or 98% of the ISPs are participating...
>>
>> 
>>
>Again, I didn't say block *all* packets, it's only user-space to
>user-space.  Please read fully.
>
>>>pessimists give me every reason that it won't work.  The thing that so
>>>many people don't seem to understand is that you don't know if something
>>>will work until you try it.  I've spent my entire adult working life
>>>doing things that people say is impossible for whatever reason.
>>>   
>>>
>>
>>"Maybe, just *maybe*, I can be the one who can have dinner with 
>>Jeffrey Dahlmer
>>safely, even though the *last* 23 people ended up *being* dinner..."
>>
>>If people are saying "BTDTGTTTOTTS"(*), it's usually a good idea to look
>>at exactly *why*, and make sure your proposal deals with the 
>>previous attempt's
>>failure in a *realistic* manner.
>>
>>For instance, any proposal that assumes all 3,000 ISPs in the US 
>>will participate
>>willingly and honestly is doomed to failure.  In fact, even one 
>>that requires them
>>all to follow the *law* is suspect - there's too many known cases 
>>where ISP's will
>>break the laws when it suits them...
>> 
>>
>I don't assume anything.  My original idea could be cultivated into
>something that *could* be used by ISPs.  Just because 23 people have
>thought about the problem doesn't mean that those 23 people thought of
>everything.  I'm not saying that I have, but from what I've seen on the
>DShield list and in other places, some of my ideas haven't been addressed.
>
>Your philosophy is similar to why rapes and murders happen in front of
>people in large cities.  Everyone that passes and sees the problem
>thinks that someone else is already doing something about it, so they
>don't bother.  The reality is that in fact, nobody called the police,
>nobody ran to help the victim, nobody wanted to try, because they
>thought something was already being done.  You seem like you would
>rather not try because you assume that people have already thought of
>everything.  The truth is that people need to try even when they think
>that other people may already be involved.
>
>>>>Vernon Schryver got so tired of hearing modifications on the same 
>>>>exact anti-spam
>  >>>ideas by people who didn't realize that maybe the idea had been 
>already thought
>>>>of, examined, and discarded as unworkable multiple times, that he 
>>>>wrote this:
>>>>
>>>>http://www.rhyolite.com/anti-spam/you-might-be.html
>>>>
>>>>(For bonus points - why did Vernon put the "critical thinker" 
>>>>entry on there?)
>>>>     
>>>>
>>>Has this idea been brought up before?
>>>   
>>>
>>
>>Yes, multiple times.
>> 
>>
>This exact idea or just parts of it?  Or are you just saying that
>because someone *must* have already thought of it?
>
>>Vern put "critical thinker" in there because it's generally considered an
>>important part of protocol design - if you haven't already thought of and
>>fixed the first dozen or so fatal issues, you haven't studied the problem
>>enough.  Bruce Schneier mentions a similar concept in his book "Applied
>>Cryptography", where he notes that *anybody* can design a crypto system that
>>they aren't able to break.  It takes genius to create one that nobody *else*
>>can break either.
>> 
>>
>This is exactly why I didn't try to think of everything.  Critical
>thinker on that page seemed to say that no invidual can possibly think
>of everything, so people that think they can are only fooling
>themselves.  I didn't assume that I could think of everything, so I
>posted here for brainstorming.  You seem to think that I posted a fully
>developed proposal that was ready to be sent to all the ISPs of the
>world thinking they would happily jump on board.
>
>>And rest assured that the malware authors *will* be thinking of ways to make
>>an end run around this sort of system...
>>
>>(*) BTDTGTTOTTS - Been There, Done That, Got Tire Tracks On The T-Shirt....
>> 
>>
>
>Again, if you don't try things because someone *will* think of ways to
>exploit it, then nothing will be created..... ever.  Every system that
>has ever been created has a way around it if someone looks hard enough. 
>Even if the system is perfect, social engineering is still a reality. 
>Your statement implies that we should never try anything because it
>might be exploited.  Systems still need to be written, they need to be
>implemented, even if you know there is the possibility that it will be
>exploited.  The solution is to stay vigilant.  Anyone that writes
>software or develops process flow and doesn't think their system can be
>exploited is sadly mistaken, and they are the least prepared when it
>does happen, but it shouldn't prevent them from creating their system.
>
>Don't take this email as a flame, because it's not.  It just looks as
>though (possibly mistakenly) you would rather do nothing than try to
>make things better.  Your criticism seems to be based on you not reading
>my response or believing that there are new ideas.  Even if there was
>only *one* thing about my idea that was new and the rest has been beaten
>to death, then that one new thing needs to be examined, not dismissed
>because you think that a group of people can think of everything so
>there's no need for anyone to worry about it any more.
>
>--
>Thanks,
>Laura Vance
>Systems Engineer
>Winfree Academy Charter Schools
>
>
>_________________________________________
>Learn about Intrusion Detection in Depth from the comfort of your own couch:
>https://www.sans.org/athome/details.php?id=1341&d=1
>
>_______________________________________________
>send all posts to list at lists.dshield.org
>To change your subscription options (or unsubscribe), see: 
>http://www.dshield.org/mailman/listinfo/list


-- 

Tom Shaw - Chief Engineer, OITC
<tshaw at oitc.com>, http://www.oitc.com/
US Phone Numbers: 321-984-3714, 321-729-6258(fax), 
321-258-2475(cell/voice mail,pager)
Text Paging: http://www.oitc.com/Pager/sendmessage.html
AIM/iChat: trshaw at mac.com
skype: trshaw


More information about the list mailing list