Re: issues with redirecting SMTP
Hi
On Tue, Sep 26, 2000 at 05:10:09PM -0400, Paul Reavis wrote:
[snip]
> source. I.e., it thinks the SMTP connection is coming from the
> firewall.
As far as I know, the port forwarding with
ipchains/ipmasqadm/ipportfw or whatever the commands are (I
haven't used port forwarding before. Just simple tcp proxies
like redir.) allow the internal machine(s) to see the original
IP address.
[snip]
> It also makes me wonder what other services would suffer. I do
> use tcpd to wrap the redir command, so at least some
> protection is there, but if daemons on the perimeter box
> (which supplies www, ftp, and smtp) always think packets are
> coming from the firewall then they can't perform
> protocol-specific validation that depends on the origin IP
> address.
Well, authentication that relies on the IP address is suspect.
Another problem with using redir or similar proxies is that your
logs will all have the IP address of the firewall in them. You
might be able to write a script to match your redir logs with
the logs on the internal machines, but this would be a pain.
If you process your web logs for stats, for example, you won't
be able to tell where people are connecting to your site from if
your web logs show the connections coming from the firewall.
> Any thoughts on the matter from you smart folks? I have some
> general questions:
> 1) should I be using a forward-only SMTP server at the
> firewall, rather than port forwarding?
I prefer this solution, because you have another layer of
defense. Someone can't talk "directly" to your internal SMTP
server. They have to talk to the SMTP server on the firewall
and then that talks to your internal SMTP server. Also, I
mistrust port forwarding :)
> 2) should I be using something other than redir for port
> forwarding?
If you want to use port forwarding/simple tcp proxying, you
could try out the ipchains/ipportfw/whatever method. (As I
mentioned above, I've not tried this.)
> 3) are there any other holes I'm missing due to this setup?
Well, people can talk directly to the services on your internal
machine that you allow them to. In which case, what's your
firewall doing for you? :) Of course the firewall could allow
you to run NFS/SMB/whatever internally, so I'm not saying you
should get rid of it. It's just that you still allow people to
talk directly to certain services on cartain machine anyway. I
would personally prefer to have a simple SMTP server on the
firewall to handle SMTP, a simple web proxy to handle HTTP, a
simple FTP proxy (e.g. SuSE's ftp proxy in their proxy-suite)
for FTP etc. But maybe that's just me :)
[snip]
> Interestingly enough, SAINT quit complaining about SMTP
> relaying when I switched to exim, but the `telnet
> mail-abuse.org` verifier still complained until I turned off
> relaying for the firewall.
SAINT might be looking for the SMTP banner. It probably doesn't
try to relay something, because that might work just because
it's running on a machine on your network or something (i.e. a
"localnet" IP.) I suspect it knows that Exim does not relay by
default, so it says it's OK when it sees the Exim banner.
Hope all that makes sense and is of some use to you.
P.S. I don't use SuSE, but I have used their FTP proxy and it
seems to work. It does not require you to run SuSE for it to
work, so don't be scared off just because they wrote it :)
--
Michael Wood | Tel: +27 21 762 0276 | http://www.kingsley.co.za/
wood@kingsley.co.za | Fax: +27 21 761 9930 | Kingsley Technologies
Reply to: