samba backup through firewall

Discussion in 'Computer Security' started by David A. Osborn, May 15, 2005.

  1. 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?
    David A. Osborn, May 15, 2005
    #1
    1. Advertising

  2. David A. Osborn

    Moe Trin Guest

    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
    Moe Trin, May 15, 2005
    #2
    1. Advertising

  3. David A. Osborn

    Winged Guest

    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
    Winged, May 16, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raffi
    Replies:
    4
    Views:
    867
    Raffi
    Feb 6, 2004
  2. Mirek

    Samba PDC and PIX Firewall

    Mirek, Feb 19, 2004, in forum: Cisco
    Replies:
    0
    Views:
    449
    Mirek
    Feb 19, 2004
  3. =?iso-8859-2?q?Micha=B3_Iwaszko?=

    IPSec + rdesktop/samba problem.

    =?iso-8859-2?q?Micha=B3_Iwaszko?=, Jan 27, 2005, in forum: Cisco
    Replies:
    8
    Views:
    794
    =?iso-8859-2?q?Micha=B3_Iwaszko?=
    Feb 3, 2005
  4. John
    Replies:
    1
    Views:
    524
    Walter Roberson
    Oct 4, 2005
  5. DaveT
    Replies:
    8
    Views:
    527
Loading...

Share This Page