Monday, February 16, 2004
A better design for a web server
We're about to order a new web server, so I've been thinking about new
(better?) ways of setting up a large web server environment.
Web servers are probably the single biggest security threat on any network.
We'd like to minimise that threat, as well as ensure maintainability and
performance.
My first thought is that we should be running the web server in a jail(8).
But not a conventional sort of a jail, one where we run only the web server
software and nothing else.
The idea is that users at Rhodes connect to the real machine, and all
updates are done there. We allow samba and/or ftp to the machine,
preferably chrooting connections into their home space. We create one user
account per department/whatever and that account has only access to that bit
of the filesystem. We can get samba to enforce permissions and group
ownership, meaning that the web unit can still update the pages.
No users, other than admin users and the web team should have a shell
account on the machine. sshd runs on the real machine.
The real machine sits on the 146.231.128.0/21 subnet, just like all other
services. It only binds one IP address on this subnet.
The httpd runs inside a jail. This is a chrooted environment in which all
filesystems are mounted read only. The exceptions are /var/log and /tmp
inside the jail, which need to be read-write. We can achieve this by having
them on their own slice which gets mounted rw. By setting a
kern.securelevel of 3 inside the jail, we can enforce a good deal of
security. This doesn't affect the real machine.
We can also play with chflags(1) and append only logs. Inside the jail, we
are secure level 3 and these flags can't be changed. Outside the jail, we
are secure level 1 and we can. Thus logs can be rotated outside the jail,
but not edited inside the jail. This is an idea only though.
The jailed machine sits on our external subnet, 192.42.99.0/24. This means
it is outside the firewall, and needs to run its own firewall. This
firewall should be very restrictive and default to deny. Multiple IP
addresses (one per SSL context) are needed here.
If the jailed machine is compromised, we are ensured data integrity of the
real machine. All we need do is reinstall the jail.
Mysql is used extensively by the web server, and I'd rather not run a mysqld
inside the jail. The problem with this is that connections then have to go
through the Rhodes firewall, which I'd like to avoid. The simple solution
to this is to put the mysql unix domain socket inside the chrooted
environment. That way, the web server talks to the socket and thus to the
mysqld running outside the jail. The downside is that we have to use a
mysqld on localhost.
Rhodes' proxy servers would need to be adjusted so that they considered
192.42.99.0/24 "local" and didn't charge for them. The main firewall would
also have to allow direct (bypassing the proxy server) connections to that
subnet. This is as easy as
add allow tcp from 146.231.0.0/16 to { 146.231.0.0/16 or 192.42.99.0/24 } http,https
add deny tcp from 146.2310.0.0/16 to any http,https
(in fact, there is probably a one-lined to do this :). The proxy.pac file
would also have to be adjusted to consider 192.42.99.0/24 "local". The
fundamental thing though is that nothing should really trust 192.42.99.0/24.
All trusted communication should happen on the 146.231.128.0/21 interface.
The next problem I need to get my mind around is how to move all the
existing content on www.ru.ac.za without copying across the tons of crud.
posted by guy at: 00:00 SAST |
path: /systems |
permanent link
