1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
=cut
TITLE=preparing the web-server
DESCRIPTION=how to get your web-server ready for remstats
KEYWORDS=install
DOCTOP=index
DOCPREV=install-servers
DOCNEXT=configuration
=pod
=head1 Getting your web-server ready for remstats
=head2 Choosing userid for remstats
Almost all the remstats web-pages are generated by some kind of CGI
script. Many of them will read additional files not available under the
html directory tree. In order to provide access to these files, you need
to make sure that the scripts get run as the remstats user. The simplest
way to do this is to run a separate instance of the web-server software
as the remstats user. You may have other methods of accomplishing this,
depending on the web-server you're using. (See also
L<remstats user|install-user>.)
=head2 Running CGI scripts under the remstats tree
You also may need to tell your web-server that C<xxx.cgi> means that this
file is a CGI script and needs to be run, instead of just displayed. With
the L<apache|http://httpd.apache.org> web-server, you could add the following
lines to the C<httpd.conf> file:
<Directory @@HTMLDIR@@>
Options FollowSymlinks ExecCGI
AddHandler cgi-script .cgi
</Directory>
=head2 Restricting access to CGI scripts
There are a few things you should do before telling others about remstats.
Remstats comes with a few CGI scripts which you probably don't want to make
publicly available and two that you certainly don't. C<ping.cgi>,
C<traceroute.cgi> and C<whois.cgi> should probably be restricted to your
own organization, unless you don't mind letting anyone on the Internet run
pings, traceroutes and whois queries from your domain. Rectricted to your
domain, you only have to worry about your own people.
However, C<alert.cgi> and C<log-event.cgi> are a different kettle of fish.
They will permit anyone who can run it to quench alerts and log comments
about them. You will probably want to be a bit more restrictive about
who you let run this.
Using the L<apache|http://httpd.apache.org/> web-server, you can restrict
the use of these CGIs using a C<.htaccess> file something like this:
# Note that this example uses the private network 192.168.0.0.
# Stuff to make Apache expire the files to get them refreshed
ExpiresActive on
# images every 5 minutes, when the data gets updated
ExpiresByType image/gif M300
ExpiresByType image/png M300
# html every day
ExpiresByType text/html M300
# What to allow
Options ExecCGI FollowSymlinks Indexes
<Files "^(whois.cgi|traceroute.cgi|ping.cgi)$">
order deny,allow
deny from all
allow from 192.168. 127.0.0.1
</Files>
<Files "^(alert.cgi|log-event.cgi)$">
order deny,allow
deny from all
allow from 192.168.20.1 192.168.23.3
</Files>
# How they're allowed in
order deny,allow
allow from all
I won't claim the IP#-based access-control is completely safe, but it's
easy and keeps out casual browsers. If you B<really> need to keep
this information safe, use a secure web-server, say apache with mod_ssl.
If that's not good enough, you ought to consider whether this stuff
really belongs on a network at all.
|
