📄 ch03.htm
字号:
<PRE><FONT COLOR="#0066FF">The current userid and group for httpd: nobody , nogroup
</FONT></PRE>
<P>For this example, we've parsed only the httpd.conf file, but the HTTPD module
allows you to parse any or all of the configuration files for the httpd.</P>
<P>This example is easily extended to print a nice report for any or all of the current
values for the configurable parameters in the httpd configuration files. Some of
the more important ones can be displayed with the following script:</P>
<PRE><FONT COLOR="#0066FF">use HTTPD::Config;
$conf = `/usr/local/etc/httpd/conf';
@files = qw(httpd.conf srm.conf access.conf);
$V= new HTTPD::Config (SERVER => NCSA,
SERVER_ROOT => $conf,
FILES => [@files]);
print "Userid: ", $V->user,"\n";
print "Group: ", $V->group,"\n";
print "Administrator is: ", $V->server_admin,"\n";
print "Running at port: ", $V->port,"\n";
print "Access filename: ",$V->access_file_name,"\n";
</FONT></PRE>
<P>This gives:</P>
<PRE><FONT COLOR="#0066FF">Userid: nobody
Group: nogroup
Administrator is: wmiddlet@adobe.com
Running at port: 80
Access filename: .privaccess
</FONT></PRE>
<P>We'll be developing this example further using the HTTPD module to keep an eye
on the directory-specific parameters a bit later. First, though, we need to take
a look at a few more relevant issues. (For this example and others to follow, I used
an unreleased version of HTTPD:: config. By the time you read this, the released
version will be available in Doug MacEachern's CPAN directory.)</P>
<P>Other security issues to consider when configuring a server under UNIX include
the following options:
<UL>
<LI>Server-Side Includes: This is a common feature of many servers, but enabling
it is something to consider carefully. It's possible, for instance, for an unsavory
individual to arrange to make the password file on your server available to anyone
through the use of a Server-Side Includes directive. These directives are especially
dangerous if they can direct the server to execute a given command within the directive.
The capabilities of server-side includes varies from server to server, but enabling
anything but the ability to include files within the archive-tree (htdocs) is generally
discouraged. (Includes NOEXEC) Server-side includes can, and should, be enabled on
a per-directory basis. Given this fact, you should never enable them in cgi-bin directories.
</UL>
<UL>
<LI>Symbolic Links: Some servers will automatically follow a symbolic link if you
enable them to do so. This, then, is another feature to consider carefully before
enabling it. The option that allows links to be followed only if they belong to the
same user as the link is generally a good one to turn on. (Sym Links If Owner Match)
</UL>
<UL>
<LI>User Directories: Most servers include the configuration item that enables the
general URL http://yourhost.com/~username to work. Enabling this feature implies
that each user on the server can create a directory in his or her home directory,
usually called public_html, within and beneath which users can create their own archive
of files to be served by extending the ~username URL. Enabling this feature simplifies
the administrative hassles of creating a separate directory under the master archive
for each user who wishes to populate his or her own space, but also creates the potential
for unwary users to create holes. Another aspect and configuration option related
to this capability and the symbolic-links capability is the "If Owner Match"
option, mentioned previously, which instructs the server to follow symbolic links
only if the file that is pointed to is owned by the same userid as the link that
points to it.
</UL>
<UL>
<LI>Automatic Directory Listings: (Indexes) Turning this option on will allow the
client to receive a listing of the directory if it contains no index.html. This is
a convenient and widely used option but should be enabled with care. Allowing the
client to know about every single file in the directory may introduce a security
hole by giving the client access to files that are not intended to be seen. Things
like emacs backup files, symbolic links created for your convenience, and other types
of temporary files, as well as source code, may be unfit for public consumption.
Always be sure to clean up carefully when working within the DocumentRoot.
</UL>
<P>So, given all of the configuration options available to protect your server within
the httpd configuration files, we can use Perl to help ensure we haven't overlooked
anything and that the important variables we've mentioned are set according to our
preference. The HTTPD module gives us this capability. The following script builds
on our previous simple examples and gives additional information on the directory-specific
configuration options discussed in the preceding list:</P>
<PRE><FONT COLOR="#0066FF">use HTTPD::Config;
$conf = `/usr/local/etc/httpd/conf';
@files = qw(httpd.conf srm.conf access.conf);
$V= new HTTPD::Config (SERVER => NCSA,
SERVER_ROOT => $conf,
FILES => [@files]);
print "Userid: ", $V->user,"\n";
print "Group: ", $V->group,"\n";
print "Administrator is: ", $V->server_admin,"\n";
print "Running at port: ", $V->port,"\n";
print "Access filename: ",$V->access_file_name,"\n";
print "User Directory: ", $V->user_dir,"\n";
print "Global Types:\t", join("\n\t\t",$V->add_type);
print "\n\n";
foreach $dir (keys %{$V->{`Directory'}}){
print "Options for Directory: $dir\n";
while(($opt,$val) = each %{$V->{`Directory'}{$dir}{`OPTIONS'}}){
print "\t",$opt, " : ", @{$val},"\n";
}
print "\n";
}
</FONT></PRE>
<P>Which gives the following output:</P>
<PRE><FONT COLOR="#0066FF">Userid: nobody
Group: nogroup
Administrator is: wmiddlet@adobe.com
Running at port: 80
Access filename: .privaccess
User Directory: public_html
Global Types: text/x-server-parsed-html .shtml
application/x-httpd-cgi .cgi
Options for Directory: /usr/local/etc/httpd/cgi-bin
Options : None
AllowOverride : None
Options for Directory: /usr/local/etc/httpd/htdocs
order : allow,deny
Options : Indexes FollowSymLinks
allow : from all
AllowOverride : All
</FONT></PRE>
<P>Now this example has developed into a fairly useful script, which could be run,
perhaps nightly, and compared to some known preferences. If anything has changed,
either accidentally or otherwise, in your site's configuration, you can take action
immediately.</P>
<P>You'll notice from the preceding output that two additional types have been enabled
to allow CGI scripts anywhere via the .cgi extension and server-side includes or
server-side parsing via the .shtml extension. As mentioned previously, these options
should be considered very carefully before enabling them in the first place.</P>
<P>If you're using the Apache server, there are some additional configuration directives
you might be interested in; one in particular is called <TT>AddHandler</TT>. As of
the writing of this chapter, the HTTPD module doesn't automatically create a method
to dump these out because they're a fairly recent feature for Apache httpd servers.
Their intent is to configure the Apache server to use a dynamic module (akin to a
Perl5 extension) to handle certain types of requests, as opposed to a CGI script
or some other mechanism. In order to get at their settings and since we don't have
a built-in method yet, we'll cheat a bit and access the HTTPD object's instance variables
directly to extend the previous script to handle the additional parameter:</P>
<PRE><FONT COLOR="#0066FF">use HTTPD::Config;
$conf = `/usr/local/etc/httpd/conf';
@files = qw(httpd.conf srm.conf access.conf);
$V= new HTTPD::Config (SERVER => Apache,
SERVER_ROOT => $conf,
FILES => [@files]);
print "Userid: ", $V->user,"\n";
print "Group: ", $V->group,"\n";
print "Administrator is: ", $V->server_admin,"\n";
print "Running at port: ", $V->port,"\n";
print "Access filename: ",$V->access_file_name,"\n";
print "User Directory: ", $V->user_dir,"\n";
print "Global Types:\t", join("\n\t\t",$V->add_type),"\n";
print "Global Handlers:\t", join("\n\t\t\t",@{$V->{AddHandler}});
print "\n\n";
foreach $dir (keys %{$V->{`Directory'}}){
print "Options for Directory: $dir\n";
while(($opt,$val) = each %{$V->{`Directory'}{$dir}{`OPTIONS'}}){
print "\t",$opt, " : ", @{$val},"\n";
}
print "\n";
}
</FONT></PRE>
<P>Now we get the complete output for our Apache server:</P>
<PRE><FONT COLOR="#0066FF">Userid: nobody
Group: nogroup
Administrator is: wmiddlet@adobe.com
Running at port: 80
Access filename: .privaccess
User Directory: public_html
Global Types: text/x-server-parsed-html .shtml
application/x-httpd-cgi .cgi
Global Handlers: cgi-script .cgi
server-parsed .shtml
byte-serve .pdf
Options for Directory: /usr/local/etc/httpd/cgi-bin
Options : None
AllowOverride : None
Options for Directory: /usr/local/etc/httpd/htdocs
AddType : text/html .shtml
order : allow,deny
Options : Indexes FollowSymLinks
allow : from all
AllowOverride : All
</FONT></PRE>
<P>This output indicates that there are three handler modules configured for our
Apache server, and they each have specific extensions that trigger them. Note how
we created the <TT>HTTPD::Config</TT> object using the value <TT>Apache</TT> for
the <TT>SERVER</TT> parameter. As mentioned, we also accessed the HTTPD object directly
via the <TT>$V->{`AddType'}</TT> reference, which pointed at an array. Ideally,
we would submit a patch to the author of the HTTPD module so that the preferred mechanism
would work.
<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">File Permissions
Setup and Monitoring Changes in the System</FONT></H4>
<P>Another aspect of server configuration to consider is the permissions on the programs,
directories, logs, and configuration files themselves, which comprise the installed
httpd server. In general, under UNIX, the installation of an http server will create
the following directories with their intent:
<TABLE BORDER="0">
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT">cgi-bin</TD>
<TD ALIGN="LEFT">CGI programs to be executed by the server</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT">conf</TD>
<TD ALIGN="LEFT">Configuration files for the server</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT">htdocs</TD>
<TD ALIGN="LEFT">The top-level directory for the archive</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT">icons/images</TD>
<TD ALIGN="LEFT">Common image files and icon bitmaps</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT">logs</TD>
<TD ALIGN="LEFT">Logfiles are created here by httpd</TD>
</TR>
<TR ALIGN="LEFT" rowspan="1">
<TD WIDTH="81" ALIGN="LEFT"><FONT COLOR="#000000">support</FONT></TD>
<TD ALIGN="LEFT"><FONT COLOR="#000000">Programs used for maintenance of the server</FONT></TD>
</TR>
</TABLE>
</P>
<P>The important thing here is to be sure that the appropriate access is afforded
to the appropriate components of this structure, while maintaining privacy and some
level of security through obscurity against uninvited snoopers. If you're managing
your archive as a team, you will probably create a group-ID for the members of the
team who will be modifying the contents. These people may also need to access the
files within the directories listed in the preceding list. Thus, it's recommended
(see Practical Internet and UNIX Security, O'Reilly, 1996) to make all of the files
and directories within the list owned by root and accessible by the group you've
created for the Web team--something like this:</P>
<PRE><FONT COLOR="#0066FF">drwx--x--x 2 root www 512 May 10 21:36 cgi-bin/
drwx------ 2 root www 512 Jul 20 16:11 conf/
drwxr-xr-x 3 root www 512 May 14 16:02 htdocs/
-rwx------ 1 root www 155648 May 5 15:33 httpd*
drwxr-xr-x 2 root www 1024 Feb 17 00:32 icons/
drwx------ 2 root www 512 Jun 23 11:28 logs/
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -