I think he has some good advice and I thought I would share it:

The intrusion was detected late on Sunday evening when we noticed the Big Brother monitoring system was reporting two instances of the inetd process. One of these instances was the attacker(s) shell process. As an immediate precaution to prevent the possibility of further damage, lizard was powered off and another computer was configured to serve the essential parts of http://www.ru.ac.za/. This necessitated the first post in this thread, which was deliberately vauge in order to allow us more time to conduct a thorough investigation. Investigations into the extent of the damage started early this morning. Thus far we've been unable to establish any major damage. We suspect this is largely because the attacker(s) failed to gain access to a priveledged account. From an academic perspective, this shows the value of sandbox account. From our investigations it appears likely that the attacker(s) were intending to use the machine as a file server to facilitate the distribution of warez via an IRC server as well as provide general shell access for other activities. During the course of today a number of changes have been made to the configuration of the web server in order to make a reoccurance less likely. These include installing a significantly more restrictive firewall on the machine, upgrading a large proportion of the server software, re-evaluating file permissions and the removal of unneccessary software as well as a number of outdated parts of the University's web page. These changes will no doubt have some impact on what users can do with the web server -- in particular, access to the anonymous FTP server running on the same machine (ftp://ftp.ru.ac.za/) is now severely curtailed for users outside the University. Normal services to this web server are in the process of being restored. It may take several hours for DNS to propogate to all parts of the campus. It is important to understand that this compromise was most likely not as a result of a security vulnerability in the Apache web server software we use, nor in the PHP scripting language we make extensive use of, but rather in a dynamic web page or script written by one of the users of the machine. Given the uncontrolled nature of data on the University's web server it is not inconceivable that this sort of compromise may happen again. Whilst the IT Division takes reasonable precautions to secure the operating system and server software running on all the machines it maintains, exploits such as this often (and in this case did) come from user-installed software and scripts. In an open environment such as a University it is impossible to ensure that every single one of the 131423 files that are accessible via the web from http://www.ru.ac.za/ is completely secure and that all 222 users (ranging from departmental secretaries, academics and student societies to systems staff) with upload access to the machine have an in-depth understanding of the security implications of their data. This highlights the need for users to keep appropriate backups, as well as the need to contact the Web Unit (webmaster@ru.ac.za) in cases of uncertainty.