Ben Nagy wrote:
>
> Aaron wrote:
> >
> > The web developers have kept it like this so that they can
> > "browse" in windows
> > to the web server and change sites while they're live.
>
> Tell them to learn about UNC paths and deal with it.
Here's a spiffy idea that actually works, and I think it might
even add some security:
- Setup a *nix box (linux? whatever) on your internal network.
- Install Samba on it
- Have it be a member of your internal domain
- Allow only this box to communicate with the DMZ hosts via
NetBIOS.
- Use smbmount to mount all the necessary shares on the DMZ
servers.
- Re-publish those mounts on the linux server, so that the
internal network can see all of them
Voila!
All of a sudden you've got a NetBIOS "proxy"!
Benefits:
- Completely browsable from the internal network
- Internal lusers can log on with their own identities to
the *nix machine, no cached passwords on the clients
- All DMZ usernames and passwords are stored only on the
*nix machine; you can change the DMZ logons as often
as you please without having to wipe cache files on
all clients
- The internal machines won't accidentally be attempting
to log on to the DMZ machines with their internal
identities (which is what happens by default).
- I trust the Samba people to write secure NetBIOS/SMB
clients more than I do the Microsoft people :)
Drawback:
- You'll double the amount traffic used to talk to the
DMZ machines
- You have another single point of failure in the
administration.
Wether or not this is problem depends on your setup.
(My guess is: not a problem)
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
Phone: +46 (0)660 29 92 00 Direct: +46 (0)660 29 92 05
Mobile: +46 (0)70 66 77 636 Fax: +46 (0)660 122 50
WWW: http://www.enternet.se/ E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
