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

Neil Richardson neilr at ieee.org
Sat Jan 14 18:19:41 GMT 2006

Hash: SHA1
[Multi-thought post].  (Warning: I haven't had my caffeine yet this
morning.  ;-)

Thought #1:
One problem to consider is that the idea of blocking
connections/messages from known trouble-makers is also the basis of
spam blacklists/whitelists, etc.  Given how often the dual topics of
"who runs a good blocklist" and "how do I get off a blacklist" come
up, I'd say there's still some bugs to work out.  ;-)

Thought #2:
Another problem is that the ISPs have the technology *right now* to
drastically slow the spread of malware: ingress/egress IP filtering,
and block outbound SMTP connections.  How many ISPs actually implement
either one?

on 1/13/2006 5:21 PM Cefiar said the following:

> On Saturday 14 January 2006 03:08, Laura Vance wrote:
>> The ISPs don't have to start blocking until a majority of ISPs
>> are onboard with the system. The rest of the system would be
>> fine, and they wouldn't even have to kick the user off if
>> Cefiar's suggestion was used about limiting the infected machine
>> to only run utilities to repair it before their link is opened
>> back up fully. It would also serve as a notification that the
>> user is infected... and, most importantly, it could be mostly
>> automated.

Thought #3:
Someone brought up the issue of we-say-we-block-but-we-don't...didn't
spammers used to get "pink contracts" where they would pay a little
more and the ISP would look the other way until the number of
complaints reached a certain threshold?  The system breaks down when
an ISP goes "gray."

> As an addendum to this: If the ISP then adds transparent proxying
> to the mix (even if only for the infected users), then when the
> user is infected, the ISP could redirect all web queries destined
> to systems outside of the ISP's control to a fixed webpage telling
> the user that they are infected, what with (if known), what tools
> are available to fix/manage the problem, who can help them fix it
> (eg: 3rd party companies) if they aren't compentent enough, etc.

Thought #4:
IMHO, that sounds more practical: to get the maximum number of ISPs on
board, the new system must be implemented with minimal effort (and
cost), and then be as automated as possible.  The problem is that it
requires constant scanning of the users' system to determine
infection.  For those *are* savvy enough to run a firewall, how long
until we get tired of the constant scanning and accompanying noise in
our f/w logs?

Thought #5:
I liked the other idea of giving users a NAT-router with their modem,
but that requires hardware, which has an up-front cost to the ISP.

Thought #6:
The idea I'm partial to is connection-throttling, where you regulate
the number of outbound SYN or SYN/ACK packets (for TCP).  (Don't know
an easy fix for UDP, someone more knowledgeable than I would have to
look at that.)  Just playing around in a spreadsheet for a moment, I
kinda like a throttle formula of   (x/M)^D )   where x = number of
connections per second, M is the max connections before throttling
kicks in, and D is the "decay power".

Of course, using my own reasoning from Thought #4 ( ~"the new system
must have minimal effort and then be automated" ) this would never
work, because you have to install it internally (as well as at your
borders, or else you're not slowing internal infections) and no
network is going to want to do that.

> I'm happy with the idea if it's implemented right, and in a way
> that an ISP
> can easily manage. Part of the idea with my previous suggestion of
> having the user moved to a designated IP range based on their
> status (NAT equivalent, some blocked ports, open, infected) allows
> easy segregation at any router along the way using null routing or
> firewalling (as appropriate).

Thought #7:
I love the idea, but sadly I don't think existing networks would be
willing to re-segregate their networks to support this.  :~(

- -Neil R.
- --
Supreme Lord High Commander and Keeper of the Holy Potato
- ----------
PGP Fingerprint: A663 1ACB 84E6 F4DE B86E  0AA1 7A36 F817 E098 F32E
- ----------
"(Actually, it's a buck-and-a-quarter quarter-staff;
 but I ain't tellin' him that)."

Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

More information about the list mailing list