[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: issues with redirecting SMTP



Thanks for the help/suggestions. Some comments:

Michael Wood noted:
>> 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 :)

I can see your point re: proxies, though I haven't really messed with
them (and mistrust anything I don't have experience with :-)

However, the firewall is still serving some useful functions:
1) front-line defense against bad/malicious packets
2) protects against accidental exposure of non-public ports (I don't put
NFS/SMB on my perimeter box, but that's the sort of thing to guard
against)
3) prevents leveraging information gained from one service against
another - especially since I use actual unix accounts for mail, and
these presumably have mediocre passwords; if someone managed to sniff a
password from pop3 or smtp traffic, they would not be able to directly
use it to log in, since ssh goes to the firewall not the mail server.
Ditto http, etc.

As Michael Meskes and others noted, transparent proxying is a good
solution. This works fine when I run redir in daemon mode, but doesn't
seem to work in inetd mode (which doesn't surprise me). Interestingly
enough, `telnet mail-abuse.org` tries more than twice as many methods
now, but none work. The output looks much better, with exim accurately
identifying the source of the connection etc. 

Some more questions about redir:
1) what are the tradeoffs, if any, between daemon mode and inetd mode?
Is the loss of tcpd wrapping significant here?
2) what is the best way to set it up for daemon mode under debian? I'm
currently planning on either adding an /etc/init.d/redir file, with
start-stop-daemon or whatever, or alternately building my own
firewallup/firewalldown scripts with tools from Robert Ziegler's (author
of Linux Firewalls) site and dropping the ipmasq package.
3) what is the group opinion on the ipmasq package? I use a somewhat
hacked version; I like it as a nice default setup but find customizing
it to be onerous; I prefer the one-long-bash-script method for anything
complex. How secure is it, really?

Thanks for all the good help and knowledge, folks-

-- 

Paul Reavis                                      preavis@partnersoft.com
Design Lead
Partner Software, Inc.                        http://www.partnersoft.com



Reply to: