The FreeBSD Diary
Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link.
Front Page Extensions - security considerations 7 January 2000
|I don't claim to be a security expert. So treat everything I write here accordingly.|
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 # -FrontPage- testwebsite:1EWXvqbvr4rx2
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.
This strategy relies on three main points.
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
<Directory "/www"> Options Indexes FollowSymLinks ExecCGI <IfDefine FRONTPAGE> AllowOverride AuthConfig Limit Indexes Options </IfDefine> <IfDefine !FRONTPAGE> AllowOverride None </IfDefine> Order allow,deny Allow from all </Directory>
As always, if you're figured out something better, or you see a hole in the above, please add your comments.