[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 May 2005 23:29:45 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Web Server
Julian,
Others have already responded to your particular question, so I'll
comment on your suggested solution instead:
On Fri, May 20, 2005 at 07:20:53PM +0200, J.B. Lethbridge wrote:
> But, I now need to set up a web server, so that my students can use a
> forum. I believe that the sensible way to do this (security is a big
> issue), is to run the web server on a machine behind the firewall of Owl
> on one of the local network machines.
>
> These machines do not have public IPs, and so cannot be directly reached
> from outside, that is of course the idea. They talk to the net through
> the Owl machine.
>
> In other words, the students need to http to the IP of the Owl machine,
> which will direct their requests to one of the local machiensbehind it.
> These machines run Linux.
You have these four main choices:
1. "Traditional."
Setup a DMZ (a network segment behind the firewall, but different
from one with your workstations on private IPs). Place the web server
machine in the DMZ. If you ever need to run more public services, you
can either place them on the same machine with your web server, or add
more machines into the DMZ. It does not really matter whether you
place public (Internet routable) IP addresses on machines in the DMZ
or you use private addresses and NAT on the firewall, -- with
fail-close iptables filters on the firewall (default deny, allow
what's needed), there's no security difference between these approaches.
2. "For those who know what they're doing."
Place the web server machine next to the gateway/firewall machine,
on a public (Internet routable) IP address, too. Unlike the gateway,
it will have only one interface with the public IP address on it. If
you're using the same OS on both your firewall and the web server, you
do not really need to place the web server behind the firewall, -- you
can achieve the same effect by applying the appropriate iptables rules
right on the web server machine.
3. "For those who know and accept the risks they're taking."
Run the web server right on the Linux gateway/firewall machine.
4. "False sense of security."
Run the web server on a machine within your private network and do the
appropriate NAT setup on the firewall.
The first two options do not pose an additional risk to the security
of your internal network (where people might be running risky non-public
services on their workstations, such as print servers and NFS).
Options 3 and 4 are risky. You're essentially introducing a hole into
your firewall setup. Anyone having gained some access to your web
server machine (e.g., via a vulnerability in a CGI or mod_php script)
will be able to directly mount other attacks on your internal systems.
There's no significant security difference between options 3 and 4, so
you might as well pick the easiest (option 3).
A possible improvement for options 3 and 4 would be to protect your
internal network from web service compromises which do not result in a
root compromise. You do this with the appropriate iptables rules on
traffic directed into the internal interface. Obviously, if the
intruder does manage to extend their level of access to root, they'd
bypass the local iptables rules. So you do not quite achieve the
level of security possible with options 1 and 2.
I am sorry to disappoint you, but what you've been suggesting is about
the worst thing you could possibly do, security/complexity-wise.
Hope this helps.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
