I need your help for a very worthy public cause. Please read on.
As many of you may know already, e-mail and USENET news spammers are
hard at work, constantly looking for new ways to inject their messages
into the global e-mail and USENET news flow.
Traditionally, over the past 5 years or so, e-mail spammers have mostly
used unsecured and misconfigured open mail relays to send their junk
to wherever they wanted it to go. But these days, many major ISPs are
blocking e-mail from known unsecured open mail relays.
As a result, spammers have recently begun to switch tactics. They are
now actively searching for (and then exploiting) open, unsecured, and
misconfigured TCP proxies of various.
The two primary categories of TCP proxies being abused by spammers at
the present time are (1) SOCKS proxies and (1) HTTP/CONNECT proxies.
Because of the already widespread and growing abuse, primarily by
e-mail spammers, of open TCP proxies, I have created, and am now
actively maintaining a list of provably insecure and misconfigured
TCP proxies. The list is known as `proxies.relays.monkeys.com' and
it takes the form of a DNS zone, constructed in a way similar to the
well known MAPS[tm] anti-spam DNS zones (www.mail-abuse.org) and simi-
lar services such as the ORDB (www.ordb.org) and ORBZ (www.ordb.org)
lists of unsecured open mail relays.
I have already been cataloging open, unsecured, and misconfigured TCP
proxies for some time now, for spam blocking purposes, and my open
proxies list now contains over 16,500 proven unsecured TCP proxies
scattered all over the world.
Unfortunately a great many of these unsecured, abusable, and miscon-
figured TCP proxies are in fact running copies of Novell's Border-
Manager product. There are several thousand servers running Border-
Manager on my open TCP proxies list at the present time.
These installations are all running BorderManager in a way that allows
arbitrary Internet users, anywhere on earth, to connect to one or more
of the TCP ports on which BorderManager speaks the HTTP protocol, and
in a way that allows that arbitrary remote abuser to issue an HTTP
command of the general form:
CONNECT aaa.bbb.ccc.ddd:25 HTTP/1.0
followed by two carriage returns (where `aaa.bbb.ccc.ddd' is some IP
address). Such commands allow the miscreant outside abuser to effec-
tively ``tunnel through'' BorderManager, and to connect to some arbi-
trary SMTP mail server elsewhere. The spammer can then inject his
spam messages into that other mail server. Spammers use this indirect
technique because it makes them more difficult to trace.
Clearly, this is Bad News for the owner of the proxy machine. At the
very least, he/she will have some portion of their bandwidth stolen by
the spammer. Also however, the owner of the proxy may often be blamed
for the spamming activity. (The owner of the unsecured proxy _IS_ in
fact to blame, but only partially, for having facilitated the spamming.)
Anyway, I am building a set of web pages whose purpose will be to help
the local administrators at sites running BorderManager and other brands
on proxy-type products to properly configure these servers so that this
exact kind of abuse by outside spammers does not occur. My effort is
only at a very preliminary stage at this point, but you can see the
beginning of this effort here:
http://www.monkeys.com/security/proxies/
(Note that essentially all of this links on that page are NOT YET WORK-
ING.)
Anyway, I am looking for some help from Novell on this. I want to
get some real, professional, and definitive guidelines for how to
configure BorderManager in a way that avoids this exact sort of prob-
lem. I know _nothing_ about BorderManager myself, and I am not even
a user of that particular product. So I myself have nothing to con-
tribute here, other than web space to hold a page, or a set of pages
that will help people who _are_ running BorderManager to configure
their proxies correctly, in a way that avoids abuse by outsiders.
If any of you who are reading this can either (a) supply me with ex-
actly such professional and definitive configuration guidelines, or
else (b) provide me with a URL for a place where such guidelines al-
ready exist, or else (c) provide me with an e-mail address or phone
number of any person at Novell who could maybe give me such information,
then that would be most helpful.
If you can do any of these things, then please write to me at my
nominal e-mail address <r...@monkeys.com>, or if that doesn't work
(e.g. due to industrial-strength spam filtering on my end) then
please contact me instead via this form:
http://www.monkeys.com/contact.html
Thank you for your attention.
Marcel
"Ronald F. Guilmette" <r...@monkeys.com> wrote in message
news:aacf586.02030...@posting.google.com...