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/ [EMAIL PROTECTED] | Fax: +27 21 761 9930 | Kingsley Technologies
