On Tue, 22 Dec 1998, David Gillett wrote:
> I got chatting at a Christmas party with the owner of a web site
> who has twice changed ISPs because his site got hacked. He's about
> given up on ISPs to provide protection, and is looking to set up his
> own server and protect it.
(Are you talking about a co-located machine, or a virtual web server setup
for multiple customers? I'm assuming co-located...)
I'm not certain that this is something the co-locating ISP should be
responsible for. Sure, they could provide a firewall to protect a subnet
containing customer machines, but then the customers get to trust each
other. Better than nothing, but not fantastic.
I guess they could provide a single port per customer, but you tend to run
out of card slots fairly quickly (OK, so maybe you have a bunch o'
machines to do this, but it's looking unwieldy already)...
> I keep seeing recommendations that HTTP servers should be in the
> DMZ, but I'm not clear on WHY. Is this, perhaps, to protect the
> machines on the internal net from a compromised HTTP server? In this
Yup - that sounds like a good reason. Public web servers generally have a
different security profile to internal file servers.
> case, there wouldn't *be* any "rest" to protect.
> My inclination is to suggest a proxy machine as firewall, supplied
> with content from the "real" server behind it. But maybe there's a
Of course, you could always run a secure OS and web server, and maybe
dispense with the firewall box as a separate entity? You could use the
web server machine itself as its own firewall, even (hopefully I'm not
sounding too heretical?).
Just some thoughts...
Adrian Close email: [EMAIL PROTECTED]
Network Engineer phone: +61 3 8341 2400
Australian Business Access Pty Ltd fax: +61 3 8341 2499
33 Lincoln Sq. Sth. Carlton, VIC, 3053 web: http://www.aba.net.au
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
