North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Anti-spam System Idea

  • From: Lawrence Baldwin
  • Date: Mon Feb 16 10:20:34 2004

> The problem is not as much actual open relays (which are now rare and
almost universlly blocked) but open proxies

We have come up with some terms to clarify types of open proxies:

*Naturally occurring* open proxy/relay:

System on which the owner has intentionally installed a mail or proxy server
but has left it mis-configured such that anyone can relay through it.

*Synthetic* open proxy/relay:

System on which miscreant has dropped (through virus, worm, infected
download, etc.) a mail or proxy server on owners system,  thus enabling open
relaying.  By open, I mean *anyone* who discovers the ports the proxy is
listening on can utilize it.

*Synthetic* protected proxy/relay:

Same as above, but proxy contains some sort of authentication mechanism
limiting who can use the proxy...e.g. JUST the spammers....this obviously
defeats open proxy testing.

Others also refer to Synthetic proxies as "hijacked proxies" or "ProxyBots".

Some other comments on this approach:

First, I definitely agree that current RBL approaches to spam are not very
effective due to the dynamic nature of Synthetic open proxies.  Though I
can't prove it, I suspect that as much as 90% of current spam is transmitted
through such proxies...and that the majority of these proxies are installed
on compromised consumer Internet connections (cable, dsl, and yes, dialup!).

Current RBLs DO discover all types of proxies, however, it a matter of how
much time elapses between when a given IP begins to relay spam and when it
is detected and blacklisted.  I suspect that the current detection delay is
measured in at least HOURS and perhaps even DAYS.  Furthermore, many
consumer connections utilize dynamic IPs (e.g. DHCP, PPPoE, and PPP )...I
suspect that sometimes an infected system has changed IP addresses several
times before the first IP that relayed spam from is even listed!  And don't
discount dialup connections, 28.8Kbps is plenty of bandwidth to spam through
when you have 10,000 of such systems in your ProxyBot army...and the fact
that the relay's IP will change after each dialup connection means you'll
never be RBLed for very long.

DHCP, though technically dynamic addressing is far less of a problem as IP
address do NOT typically change very often...remember DHCP leases are
renewed automatically by the client when the lease is 50% to expiration.
Many DHCP clients also cache their previously leased IP (e.g. Windows) and
explicitly request the same IP even across lease expirations...depending on
the service provider, DHCP clients often maintain the same IP for months at
a time (aka "sticky IP").  Some PPPoE gateways also maintain username to IP
caches so sticky IPs can also result in that scenario as well.

I agree that strategy of not accepting mail from a given IP until it has
been open proxy tested would likely be effective in stopping proxy spam.
Unfortunately this approach is also highly irresponsible...and spammers
would quickly migrate the proxy approach to defeat open proxy testing.

In order for such scanning to be effective you would need to perform two
stages scans against 65,000 ports (if you limit to TCP only).  First you
have to find all open ports (65,000 probes * 3 for retries), then you'd need
to do at least a HTTP, SOCKS V4 and SOCKS V5 (65,000 * 3 types * 3 for
retries =585000 probes) proxy test against each of those ports.   That's
about 13MB of traffic just for the TCP scanning phase.

Although a lot of the scanning would be directed at consumer Internet users
(who probably wouldn't even notice), a significant amount would be directed
at bona-fide mail servers.  The administrators of the latter will likely NOT
appreciate this and they WILL complain.  Frankly, I think the complaints are
justified...if someone did that level of scanning into my network (on a
daily basis no less) I'd be obligated to investigate, potentially wasting
hours of time until I find out the intent behind it.  Despite the activity
having good intentions, bottom line is has wasted my multiply
that time by the 1000s of network and security administrators that would do
the same.

Even if such an approach was initially effective it would ultimately fail.
Spammers would simply migrate to authenticated proxies, proxying via UDP
(which can almost impossible to scan for), or proxying using custom
protocols thus defeating SOCKS and HTTP relaying tests.

Personally, I think the better approach to fighting proxy spam is to
identify the spammers that are *upstream* from the proxies and then get one
or more of them thrown in jail, not for spamming, but for violating federal
or state computer intrusion laws.  Spammers are currently using open proxies
because they are free and anonomous, until you make them non-anonomous AND
costly (jail) there's nothing will stop them.

This is not as hard as it sounds...if you are an ISP you have hijacked
proxies on your network.  The RBLs can tell you which IPs are hijacked
proxies,  all you need do is capture Netflow data and examine the upstream
IPs pummeling the hijacked proxy on it's SOCKS and/or HTTP proxy port.  The
results of such analysis is extremely enlightening...these spammers have NOT
moved off-shore, they are NOT using multiple levels of proxy chaining and
obfuscation, they are spamming DIRECTLY from their web hosting and corporate
offices in North America, and as is often the case, South Florida.

The other approach is to identify the "master" servers that are controlling
these ProxyBot networks (most hijacked proxies "call home" to the master to
report their IP and current proxy port info).  In the last few months I have
reverse-engineered several proxyBots and identified quite a few master
servers....some hosted at US-based web hosting companies.  If you take out a
master server, you take out 1000s or 10s of 1000s of proxies.  What amazes
me is that master servers that I identified back in Oct 2003 are STILL
operational today.  This suggests to me that almost no one is pursuing this

I suspect the problem is one of a lack of coordination within service
provider organizations.  They all want to stop spam, but they seem more
focused on preventing it from coming in vs. stopping it from going out from
their own customers.  Sorry, but if you can't even stop it from being sent
from you own subscribers you're not going to find any solutions to the more
difficult problem of blocking inbound spam.

An effective fight requires a combination of Netflow data (from network
engineering/ops), spam complaints (from Abuse dept), spam proxy code (from
customers system), and forensic examination (by security researchers or
in-house security teams).  Apply this approach across several large SP
networks and I guarantee it will become clear where the majority of spam is
really being transmitted from...


Lawrence Baldwin
Chief Forensics Officer
Atlanta, GA