The first thing I did was add an .htaccess file that only allowed web access from our desk machines. This kept everyone else from viewing the pages but didn't keep those who have accounts on the ACM web server (quite a few) from viewing the directory directly.
Originally the directory for the workshop was mode 775 and writable
by group exec. ie:
drwxrwxr-x 3 jgross exec 1536 Feb 10 20:15 securityI needed to set it up so only we could access the directory but we couldn't just make it 770 without blocking the web server from seeing it.
The solution was to make a new group called secwork put both our accounts in that group and make the directory mode 771. This was based on the assumption that those who had already seen the directory wouldn't remember the filenames of the 55 or so files:
drwxrwx--x 3 jgross secwork 1536 Feb 10 20:15 securityThis works unless the attacker realized that the index.html file contains the names of all the other files in the workshop. They can still view this file since it has to be world readable for the web server.
-rw-rw-r-- 1 jgross secwork 3311 Feb 10 21:19 index.htmlThe next step was to rename the index.html file to index.mine.html based on the assumption the attacker doesn't figure out the new name.
Even this isn't enough. If the attacker was smart they could grep for /security/ in the world readable httpd access_log. I didn't bother changing permission on the access_log. If they figure out this much I'd much rather get their input on the pages than lock them out. :)
The above methods are called Security Though Obscourity. One should never base their security policy on the attacker not knowing how the security policy works.
This example doesn't even begin to cover other attacks such as trying to hack root on the web server. Hopefully no one is that desperate to see these pages two days early.