I have a question; I've run into this particular one myself before in
trying to do transparent proxying.  Let's say you have client X trying
to connect to server Z, and you want to transparently proxy the TCP
connection through Y, which happens to know the protocol Z speaks.  In
this instance, we're talking SMTP.

So X connects to what it thinks is Z, but is really Y.  Now what I want
to do is have Y open a connection on to Z, and transparently monitor the
conversation, essentially "tee"ing it off to a SA process.  If SA starts
noticing spam, then fire off some exception.  But as far as X knows,
it's just talking to Z, and as far as Z knows, it's being talked to by
X.  I'm assuming nothing complicated like X and Z using strong
authentication here.

So, I understand how I can redirect any traffic from X on port 25 to Y. 
But how do I get Y to know the address that X intended to connect to in
the first place, so it can open the onward connection?  I suppose if Y
was itself the router, then you could introspect the redirection tables
or something, but is there some nicer way of handling things?

C

On Thu, 2002-04-04 at 00:40, Nigel Metheringham wrote:
> On Thu, 2002-04-04 at 05:23, Olivier Nicole wrote:
> 
> > BTW, a serious question. Do you any of you know if on a Cisco router
> > it is possible to do transparent redirection for SMTP?
> 
> Yes - you use policy routing.  You need a box to accept the SMTP
> sessions as the next hop  - we (when I worked at Planet Online in the UK
> - who host Freeserve which is a 3 million or so user ISP) used to do
> this on all dial ups which were trying to connect to SMTP ports outside
> our service addresses.   The intercepting servers were linux boxes using
> the transparent proxy code to pick up the forwarded sessions.  We ran
> the policy routing on the NAS (dial in) boxes - they had plenty of spare
> CPU for that sort of thing - however running it on one of the other
> router sets would have been technically possible if less scalable.
> 
> Those boxes did traffic analysis - ie bursts of mail from an IP to more
> than a particular threshold of targets were held for later release. 
> Adding SA into that pipeline would be possible, although we tended to be
> more interested in message trends rather than per message scoring - one
> highly spammy message would not be interesting, 100 spammy messages are
> much more interesting, as were 100+ attempted mail bomb/abuse runs.
> 
>       Nigel.
> -- 
> [ Nigel Metheringham           [EMAIL PROTECTED] ]
> [ - Comments in this message are my own and not ITO opinion/policy - ]
> 
> 


_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to