1998-12-23-09:59:52 Paul McNabb:
> The solution is trivial.
Solutions to trivial problems are simple. However, this is not a trivial
problem.
> Stick a trusted OS under his web server. Then he can even let people
> telnet into his web server and they still won't be able to hack it.
That could be made to work, if and only if you only want to solve a trivial
problem.
Stick a trusted OS around the web server, and configure it to prohibit
anything except the web server from accessing the web server, and then you
could allow people to telnet into the machine, and they wouldn't be able to
"hack" it, whether by "hack" you mean "corrupt or sabotage", or you simply
mean "maintain or repair". Why bother setting up a telnet daemon if you're not
going to make the incoming service useful? Better to just disable it.
But sticking a trusted OS under a web server won't help the _interesting_
problem, which is that configuration errors --- like e.g. inadequate parameter
checking in CGI scripts --- can allow requests made directly to the web server
to disrupt its functioning.
If the job at hand were to allow a web server and some unrelated activities to
share a single computer, then a trusted OS would be helpful for setting up
separate boxes for them to play in. But when the job is securing a web server
all alone by itself on the hardware so people cannot corrupt it, the part of
the job that a trusted OS can help with is too trivial to merit the complexity
and cost of a trusted OS.
Just shut down inetd, sendwhale, and any other daemons that are listening. If
you have something you need to leave running and you can't prevent it from
listening (canonical example: syslogd) slather on some packet filtering (ipfw
for Linux, ipfilter for most anything else) tp prevent others from contacting
that port. Check your work with "netstat -a".
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
