Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > samba backup through firewall

Reply
Thread Tools

samba backup through firewall

 
 
David A. Osborn
Guest
Posts: n/a
 
      05-15-2005
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
server?

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?




 
Reply With Quote
 
 
 
 
Moe Trin
Guest
Posts: n/a
 
      05-15-2005
In article <BTyhe.80113$NU4.61001@attbi_s22>, David A. Osborn wrote:

>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.


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).

NO OTHER CONNECTIONS ORIGINATED IN THE DMZ SHOULD BE PERMITTED.

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
 
Reply With Quote
 
 
 
 
Winged
Guest
Posts: n/a
 
      05-16-2005
Moe Trin wrote:
> In article <BTyhe.80113$NU4.61001@attbi_s22>, David A. Osborn wrote:
>
>
>>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.

>
>
> 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).
>
> NO OTHER CONNECTIONS ORIGINATED IN THE DMZ SHOULD BE PERMITTED.
>
> 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

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?


Winged
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java access to Microsoft Access database through Samba JC Java 3 06-18-2006 11:41 PM
Bytecc Backup Star One-Touch Backup External Enclosure @ A True Review Silverstrand Front Page News 0 11-24-2005 04:01 PM
How to backup registry without backup utility The Babaloughesian Computer Support 8 02-27-2005 04:11 AM
Backup Exec 9.1: The Backup Exec job engine system service is not responding Christian Falch Computer Support 1 06-23-2004 02:22 AM
Samba PDC and PIX Firewall Mirek Cisco 0 02-19-2004 02:25 PM



Advertisments