At 08:38 AM 4/7/2003 -0700, you wrote:
afraid of what?
Getting whacked. Wasting a spam run. Getting exposed.
rules require cooperation or policemen. What's your policeman here?
Right now the policeman is the spammer's ISP - give the ISP evidence of
abuse by the spammer and the ISP just about has to act. The honeypot
operators tell the ISPs of the abuse - the ISPs act.
Later the ISPs could largely skip the honeypot step. My honeypot was used
as the SMTP test IP for hundreds to thousands of open proxy tests in the
telesp.br domain. How hard is it for telesp.br to see the connections made
from all over their space, all to port 25 of the same IP in Wisconsin? How
hard is it for telesp.br to see the proxy connections to all their IPs, all
(probably) from the same IP elsewhere? Even if from a group of IPs the
pattern should scream out. If the ISP bothers to look. They don't have to
watch the traffic to their entire space: they could do subspaces, one at a
time.
The advantage of using honeypots may be that the operator of the honeypot
IP has an inherent right to monitor traffic to that IP, to examine it. If
the operator sees abuse traffic he has a right to report that abuse to the
appropriate ISP, who can then use that evidence to enforce its own
TOS. The ISP may hve no right to actually examine traffic (look at
packets) absent evidence of abuse. I suspect the ISP has the right to
watch for patterns of traffic that are characteristic of abuse and to
follow through on those (contact the sender, ask for the right of examining
packets. Even if he refuses the sender knows he is not getting away with
it completely undetected.)
(given that this issue is a much smaller and less devastating issue than
that of the root kiddies that own machines before the install process is
finished, and given how little progress has been made at slowing that
down, I don't see how the anti-spam world is going to make better progress
here than the entire security world has...)
Partly the key is that the abuse is so small and is always the same. It
takes no particular skill to intercept port 25 traffic to an IP that should
have no port 25 traffic. Same for 1080, etc. It's defensive script-kiddy
tactics. It can be less skilled than script-kiddy tactics: download this,
run this. Bang! You are a honeypot operator. Jackpot can report to a
central server - configure Jackpot to run that way and a whole flock of
honeypots can be run by people that only vaguely understand they are
helping fight spam.
As to the security world, they seem to emphasize making a system immune to
being rooted (as opposed to making those that try to root systems feel
pain.) Causing pain here is a much harder task, real honeypots (and
honeynets) are useful there but in this problem they are dealing at least
some with hackers who are crafting their solutions as they go, who are
finding new vulnerabilities. Even there I'd guess that ISPs could be more
creative in detecting attempts, particularly from script kiddies: if
there's a new exploit for a vulnerability on port xyz then watching traffic
to port xyz should reveal anyone who is scanning through a space looking
for a vulnerable port. Do ISPs do that or do they just run around warning
people to secure port xyz (if even that)? It's no surprise that there's
little progress.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg