Rev 13 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<br/>
Can you be sure that there is not a ``hacker'' among your students? If not, here is what (s)he may try to do to break/attack your server.
He may look for security weaknesses in a neighboring virtual class, try to steal/crack site manager's password, or more frequently, simply break into the operating system (by the way, this is an important reason why we don't port WIMS to Windows).
And if he is ever to succeed, he may be able to either destroy your virtual class, or modify it in such a manner that it becomes extremely difficult for you to find out where are the modifications. The latter can often do you more dammage than a simple destruction.
For this reason, a WIMS server aimed at real uses must be set up as securely as possible:
1. Declare a virtual class as your neighbor only when you are sure that the other class is as secure as yours.
2. Site manager's access must be set to as restrictive as possible.
3. Ideally, the server should be exclusively dedicated to WIMS, and all network accesses to it (telnet, ssh, ftp, nfs, etc.) should be closed except http (and possibly https). No user account should be created on it, except the one used for WIMS administration.
4. As site manager, periodically make security checks to the installation (for example file permission checks available in the online site maintenance tool).
In fact, if you are not very security-aware, it is more secure to install your virtual class on a remote server known to be secure, than to create your own local installation.
Generated by GNU Enscript 1.6.5.90.