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
|
Similar Threads
