What can the cgi
scripts do? |
Well, that's another story. Cgi scripts run on the server machine with the
user id and the privileges of the weserver the cgi was invoked from. They are not limited
to a sutree in the Unix file system like html docs, but they can go to any directory they
have access rights for.
So be aware of your risk when using those cgi. But if you keep open your eyes and build
some walls around them, then you shouldn't have any problems.The cfgreader.pl
cgi
This perl scripts reads Cfg files in every directoy it (the user id of the web server) has
read privileges. Because the script parses the cfg file, it can only read Cfg files using
the syntax of those written by cfgmaker.
If it reads a file which is not a cfg, it may be able to read some information, but it
will produce garbage and maybe an error message in most of the cases.
The cfgwriter.pl cgi
The cfgwriter.pl writes a file to a directory the webserver user id has access to. If it
is provided with a path to a backup directory, it will move an existing file with same
name to this backup directory. If there was no backup directory path submitted, it will
just overwrite an existing file (MC2 always submits a path to a backup directory, as
specified in the index.html file).
Cfgwriter.pl can't just write mrtg cfg files, but every file which is basically a text
file and is submitted to the cgi line by line.
I repeat: cfgwriter.pl can write any kind of text file (even perl scripts)! So make sure
the webserver user id has only write privileges to the directories it really needs to.
Write privilege to the cgi-bin directory (where all the cgis are located and can be
executed from the webserver directly) would be VERY RISKY. It could destroy your server or
even cause more damage.
The dirreader.pl
dirreader.pl reads the contents of a directory it has the rigths to. This will not cause
direct harm, but it may be usefull for a spy to get your file names.
|
How can I protect
my machine? |
I would recommend the following (we do it this way at our location):
It is usefull to have a special user and group id for all actions mc2 makes. To do this,
run a second apache webserver on which only mc2 is.
Follow my 10 Steps toward Security:
- Make sure your beloved server is behind a firewall and so protected from bad guys in the
Internet.
- Make a Copy of your web server settings (httpd.conf and srm.conf) and edit them. Change
in them all that is necessary. Set the Port to something new (maybe 8080), set the User
and Group entries to new values (I made them mc2) and set a new DocumentRoot which is
completely outside the html tree of your old server. Add a ScriptAlias entry for your cgi
scripts. The cgi-bin directory should NOT grant write access to the user id of this
webserver!
You may want to change other things as well.
- Edit your etc/inetd.conf and /etc/inet/services files and add a TCP Port (e. g. 8080).
As application for the port, choose the path to apache and the new conf file. It may look
like:
In /etc/inet/services:
http2 8080/tcp www # World Wide Web HTTP for MC2
http2 8080/udp www # World Wide Web HTTP for MC2
In /etc/inetd/conf:
http2 stream tcp nowait root /opt/apache/src/httpd httpd -f
/opt/apache/mc2/conf/httpd.conf
- Copy your cgi scripts to the cgi-bin directory
- Copy your html and class files into the html directory. The user id of the webserver (e.
g. mc2) should not be allowed to write either to the html or cgi-bin directory!
- Make a directory for your cfg files with read and write permissions to the user id of
this webserver (must not be in the html subtree; if it is, the user can see the contents
of them. May be useful).
- Protect the webserver with username and password (htaccess.conf).
- Don't forget to make a directory (with read/write privileges for mc2) for your backup
files and tell MC2 to use it (PARAM tag in the index.html file)
- Protect all directories of your Unix file system to not grant read or write privileges
to mc2 (to "all").
- You shouldn't have nightmares anymore.
I can not guarantee anything, but this should provide you with basic security features
so that you can live with it. If your server is open for public (not behind a firewall),
so you may think a little more about security.
|