Re: WWW protectors

["Marcus J. Ranum" <mjr () nfr net>]

> I'm looking for pointers to packages that protect web servers.
> So far I've found:

The question to me is "how do they protect the web server?"
One of the ways a web server gets broken into is through
stupid flaws in CGI-bin scripts. There's not a good way for
an externally developed engine to know about all the stupid
CGI-flaws the end user might invent. Another way web servers
get broken into is through buggy code in the http daemon.
This is unfortunate, since you NEED something serving web,
and that's a main point of attack. Trusted operating systems
(CMWs, etc) can help prevent the web server software from
letting an attacker gain access to the whole system, but
unless it's set up carefully they may be able to gain
access to the web pages and alter them.

My favorite design for a secure web server was one that
a sick, twisted buddy of mine came up with. You just put
a lot of lines in /etc/inetd.conf that look like:
http-8081 stream  tcp   nowait  nobody  /bin/cat  cat /cdrom/index.html
http-8082 stream  tcp   nowait  nobody  /bin/cat  cat /cdrom/docs/index.html
http-8083 stream  tcp   nowait  nobody  /bin/cat  cat /cdrom/text/doc1.html
http-8084 stream  tcp   nowait  nobody  /bin/cat  cat /cdrom/text/doc2.html
http-8085 stream  tcp   nowait  nobody  /bin/cat  cat /cdrom/text/doc3.html

Then your system needs to only have a copy of cat, inetd, and the
kernel.:) For extra credit, modify udp_input.c to throw away
anything not destined for port 53, and ip_input.c to throw away
anything destined for ports below 8081 and over 20000.

Of course it won't *DO* much but that's kind of the point. :)

The thing I don't see explained by the vendors of the products
you listed is how their products effectively manage complexity
and the fact that mistakes are end-user installable. I think
they wave their hands over the mistake issue. Which is sad because
it gives the customer a sense of false confidence. If you, the
customer, need to protect your web site, you can make a huge step
in the right direction by installing some in-kernel filtering to
restrict access to ONLY the web server daemon and DNS. Then make
sure the web server daemon runs with reduced permissions and
if possible chrooted. Lastly, audit your CGI scripts. You'll be
in pretty good shape that way.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr