samba backup through firewall

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I am currently looking for a safe way to backup my mail server to a samba
server on my local network.  Currently I have a firewall/router (IPCOP) with
three NICs.  One is the red interface that connects to the Internet, the
second is a green interface that connects to the local lan, and the third is
the orange interface that contains the mail/web server (only web ports and
mail ports open through firewall).  I would like to setup my mail/web server
on the orange interface to backup to a samba server on the local lan.  My
question is which would be safer:  Have the mail/web server share the files
and have the samba server connect to it and copy things over, or have the
web/mail server punch through the firewall and copy stuff to the samba

It seems to me that if the web/mail server connected to the samba server on
the local lan then someone who got into the web/mail server could utilize
this to get into the lan, but if I have the mail/web server sharing the
files then that may open up more vulnerabilities on the mail/web server.

Any suggestions?

Re: samba backup through firewall

Quoted text here. Click to load it

This sounds as if you are running the mail server on some windoze platform
which really isn't the greatest idea ever.  As it may.

Basic concepts: 1. "Outsiders" should have the most limited access to hosts
in the DMZ - to get files, web pages, etc. ONLY. 2. No host in the DMZ can
make a connection to the inside. ALL connections to the DMZ should be from
outside of the DMZ - from the LAN for administration, from the world to
serve files/web/whatever.  3. Hosts within the DMZ should permit connections
to other hosts in the DMZ only as absolutely needed. 4. Hosts in the DMZ
should NOT be running any application not absolutely needed to perform the
tasks they are supposed to do. In a paranoid world, no host should be
offering more than one service. Thus, should someone gain control of a DMZ
host, they are limited in what they can do.  5. If you are really, really
paranoid, hosts in the DMZ are run from read-only media, and only dynamic
content (files, web pages, etc. that is being frequently changed) being on
read-write media.  In a *nix type O/S, the dynamic media can be mounted
read-only normally, and remounted read-write when updating the files.

The safest rule for backup of a DMZ is that the DMZ doesn't retain originals.
That is, for a file, web, or DNS server located in the DMZ, the server has
"working" files, that have been copied from the source server that is located
on the _inside_ LAN. For a mail server, it accepts INCOMING SMTP mail, and
relays it to an internal mail server where distribution actually occurs. The
internal mail server uses the DMZ server as a SmartHost to relay internally
sourced mail to the outside. "Internal" to "internal" mail never leaves the
internal LAN for ANY reason.  The DMZ mail server has to know about all
internal mail accounts that are allowed to accept external mail, and REJECT
all other mail at the SMTP "Receipt to:' stage. It should NEVER accept all
mail, with the expectation of returning undeliverable mail to the "claimed"
source. The mail server should be the only host on the DMZ that is allowed
to initiate connections to the inside, and the rules should permit only
transfer from a high port on the DMZ mail server to port 25 on the internal
mail server (or if you are really paranoid, the internal mail server needs
to poll the DMZ server "frequently" to get new mail from outside).


Administrative access to hosts in the DMZ should only be permitted from a
few specific hosts on the internal LAN, with the connection originating on
the internal host, not vice versa. This means that the administrative hosts
inside will use a secure file transfer protocol like SCP (and specifically
NOT FTP, or some generic file sharing/serving protocol) to transfer files
from source to the 'working copies' held on the DMZ servers. Should you need
to retrieve material uploaded from external hosts to the DMZ, these items can
be retrieved by the same secure file transfer mechanism.  Note the concept
that because the stuff in the DMZ is all "working copies" with the originals
on hosts on the internal LAN, there is no need to back up anything from those
DMZ systems - you have it already on the inside.

If there is some bizarre reason that you must allow administrative action from
outside the LAN, make this through a tunnel to one specific host (such as the
home computer of the administrator, or a hardened host within the DMZ, or
similar). Restrict access on that host.

        Old guy

Re: samba backup through firewall

Moe Trin wrote:
Quoted text here. Click to load it
Amen.  Though your advice has much wider scope than the samba mounts, it
is good advice.  I recommend the SAMBA mounts be restricted to an SDMZ
(internally exposed DMZ).  All servers should be constrained to talk
only to those host over specified minimal required ports.  I am not sure
why one would chose to allow the mail host to talk to the samba mount
point.  I would ensure that restrictions were in  place on both servers
to prevent communication fear of Mr. Osborn.  If the web host is
compromised, servers should be configured so that layered restrictions
are in place to impede host jumping should one host be compromised.
Properly configured even if one host is compromised it does not expose
the other DMZ servers to the threat.

Has anyone had experience running MS ISA server?  I am looking at using
it as a server firewall host in front of exposed mail and web hosts.  It
appears to add extended and simple to manage filtering capabilities for
SMTP and proxies web requests with additional filtering.

Just looking to see if anyone has had any issues using ISA that I should
be aware of. Our placement of this host would be between DMZ servers and
a PIX outside boundary.  I am looking for unadvertised gotchas.  We
still are in lab testing but real world always provides surprises...anyone?


Site Timeline