Subject: anti-spam tests...

From: Matti Aarnio <[email-masked]>
Date: Thu, 5 Sep 2002 14:27:32 +0300

(lets begin a new thread, although it relates to what is been
 talked about)

One way to combat "proxy-hijack" identity hiding is to verify, that
the source system does not have open SOCKS/HTTP-CONNECT proxy.

How to do that ?

A concise way would be to contact the IP address at a bunch of
test ports (880/8008/8080/8081/squid), and issue there a CONNECT.
Try it with your local connect-proxy ("https"-proxy):

  CONNECT 2.2.2.2:25 HTTP/1.1<enter>
  <enter>

where "2.2.2.2" is your local smtp-server's IP address.
You should get a few responses from the proxy, and then your
smtp-server replies.

Something like    http://monster.cyberabuse.org/   tester:

     There are 8 steps in the process (10 seconds max for each).    
     Scan of 62.240.94.4 in progress...
     SCANNING FOR A MISCONFIGURED WINGATE PROXY (PORT 23).              
     SCANNING FOR A MISCONFIGURED SOCKS 4 (PORT 1080).
     SCANNING FOR A MISCONFIGURED SOCKS 5 (PORT 1080).                  
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 80).
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 81).              
     SCANNING FOR A MISCONFIGURED SQUID OR WINROUTE PROXY (PORT 3128).
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 8000).     
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 8080).               
     Scan of 62.240.94.4 is complete.

To avoid deadly embraces, the testing code needs to maintain
cluster-wide statistics (possibly be a server of its own),
when it begins testing (before the first connect), it needs
to mark that address is in testing, and subsequent questions
(caused by the test itself) get back an "ok" state.

Possibly the smtp-server should always respond with the normal
greeting, and only then call for the block-proxy-detector.
To speed things up, the detector could be kicked (asynchronously)
to find the answer before the 220 greeting, but actual state of
the data is asked only afterwards.

Only when the tester knows for sure that there is an open proxy,
it will begin to yield a "reject" info causing all MAIL FROM/RCPT TO
commands in the session to fail.

Caches are needed too, negative one ("ok") for at least an hour,
positive ("reject") perhaps several hours.   Possibly the positives
can have some "retest positive again, increase the time quanta"
method.  Persistent database, logs, all that..

Of course such scanners will cause occasional complaints from people
who detect their probes.

-- 
/Matti Aarnio	<[email-masked]>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to [email-masked]

---

From: [email-masked] (Alexey Lobanov)
Date: Thu, 05 Sep 2002 15:35:37 +0400

> the source system does not have open SOCKS/HTTP-CONNECT proxy.

Please also look at http://www.dsbl.org/programs.html

A set of ready GPL'ed programs by Ian Gulliver testing standard sorts of open proxies and 
relays: SMTP, HTTP, SOCKS.

Alexey

-

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Sep 2002 10:53:54 +0200

One thing I've been wanting is a reallu dynamic blacklist: One that will 
answer my query from its cache, probe for open proxies in case of a 
cache miss and then cache the result.

Ideally, it would answer with a five-minute TTL in case of a cache miss 
and three-day TTL in case of a cache hit (whether positive or 
negative).

Does any of you know about such a beast?

--Arnt
-

---

From: Rik van Riel <[email-masked]>
Date: Fri, 6 Sep 2002 10:46:22 -0300 (BRT)

> cache miss and then cache the result.

This would result in testing every host that sends you email.

Worse, if such a scheme becomes populare it'll result in every
host that I'm sending a message to testing my server. Not fun
when you're running mailing lists ;)

IMHO such a testing scheme should be distributed, we should
share each other's results so we waste less resources doing
the various tests.

> Does any of you know about such a beast?

For the positive hits, there already is a distributed system,
it's called the Distributed Server Boycott List, DSBL:

	http://dsbl.org/

It has a set of testing programs available at
http://dsbl.org/programs.html

For the negative side of things, ie. determining which servers
have already been tested by others, there doesn't seem to be
anything available yet.  You've made me think about the issue
though and I'm convinced now that we'll want something.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  [email-masked] [email-masked]

-