Things look quiet here. But I've been doing a lot of blogging at
dan.langille.org because I prefer WordPress now.
Not all my posts there are FreeBSD related.
I am in the midst of migrating The FreeBSD Diary over to WordPress
(and you can read about that here).
Once the migration is completed, I'll move the FreeBSD posts into the
new FreeBSD Diary website.
Front Page Extensions - security considerations7 January 2000
I don't claim to be a security expert. So treat everything I write here
You've come a long way baby
FrontPage 98 was notorious for security exploits. There were many holes found in
the Front Page server extensions. As far as I know, all of these concerns have been
addressed with FrontPage 2000. I've been speaking with someone who's been working
pretty hard at finding holes in it and hasn't been able to find any. People will
continue to roll their eyes and claim FP is full of holes. That's OK. They're
just repeating old news and aren't up with the latest and greatest.
As a comparison, sendmail,
at one time full of many bugs and well known exploits, now delivers most of the world's
email. But memories die hard. Some people still claim qpopper is
buggy. But that's old news too. It's been fixed.
Shell access to your webserver
If you provide shell accounts on your webserver, you should be aware of the file
permission considerations surrounding the default installation. By default, anyone
with a shell account can do this:
$ more /path/to/web-site/_vti_pvt/service.pwd
There you have a user/password combintion. It's easy enough for someone to
feed that into a password cracker.
If you don't allow shell access to your box, this isn't an issue.
If you do allow shell access to your box, here is the idea I've been playing around
with. It consists of two main points.
chgrp the files to <user id>:<webserver group> so that the user owns the
file, but the webserver can access the files.
chown the files so that they are not world readable.
This strategy relies on three main points.
Since the user owns the files, they can update, delete, etc as they wish.
The files belong to the webserver group (in my case, this group is www), which is what apache
runs under. This means the webserver can access the files as needed.
All files have permissions such as 640 or 750 so that everyone else cannot access the
The only drawback I can see with this strategy is that the users can change permissions
to give world access to files. To conteract this possibility, a script can be run
daily to search for such files. I've been given such a script and I'm going to test
it and report back. Watch this space.
I'm still looking for more comments on this strategy. Please let me know your views.
Tell your users to keep their FrontPage passwords different from their
shell passwords. If the FrontPage security is compromised, at least shell access
has not been given away.
Restrict your web site directory
There are special things you need to consider if you are placing your webpages outside
the regular document root of /usr/local/www. The following extract from http.conf
is what has been recommended to me as being able to secure such directories with respect
Options Indexes FollowSymLinks ExecCGI
AllowOverride AuthConfig Limit Indexes Options
Allow from all
As always, if you're figured out something better, or you see a hole in the above, please add your comments.