Already mentioned many points:

• Web Server logs -- access and error logs show you who is trying what against your web server(s); may point out applications you forgot about;
  • Your job as administrator is not police officer, you are looking to find out how to be safe not to find the bad guys (unless that floats your boat)
    
• Firewall logs (if applicable) -- this shows up the other services that are attempting to be attacked, at least from outside your WAN
• OS logs (if applicable) -- /var/log/syslog (common to Unix) or Event Viewer for Windows; looking for unusual activity (but to detect you must first know what usual activity looks like)
• Drupal logs -- admin/reports/dblog; useful for keeping an eye on shared administration as well as for finding signs of failed attempts
  • Such signs are useful, they tell you somebody is knocking and that your defenses are working
    

What to do if there is a problem?

You've detected unusual activity, an admin account doing unusual configuration changes, odd SQL errors, unauthorized account use, unrecognized modules, unexplained PHP failures; now:

1. Make sure you are logged in as number 1 user (if that account is compromised and you do not have a backup account to change #1 password, chmod a= settings.php to stop all access to your site; you have work beyond the scope of this lesson)
   
2. Stop the bleeding;
   
   1. If an account has been compromised, block the account immediately (admin/user/user or user/%uid/edit); 
      1. If multiple accounts or an administrative account has been compromised take site offline immediately;
         
   2. If a module seems wrong, disable it immediately (drush disable module_name; or admin/build/module);
      
      1. If module is critical to site, take site offline
         
   3. If every page access is causing logged failures, take site offline and start further investigation (likely some failed code somewhere)
      
3. Assess the situation:
   1. Don't panic -- most attacks are economically based, the target is to either use infrastructure as launching pad or (more likely) to insert malware onto your server that will affect clients to your site; malicious destruction is unlikely
   2. How long has this been going on? Look for historic log entries
   3. Are there new files in wrong places (pretty much anywhere but sites/default/files/*)?
      1. Changed configuration files (settings.php -- should be a=r except during explicit changes)
         
      2. Changed module files -- one word can make a difference, consider ACL
         
      3. Scripts / command files: perl, sh, .cmd, as well as .php
   4. Does your firewall provide any outgoing logs? Any evidence of unauthorized outgoing connections?
   5. Check your database for new or changed accounts -- admin/user/user for Drupal attacks and mysql.user for SQL attacks
   6. Check your entire site configuration as best you can (http://drupal.org/project/sitedoc is a big help and tripwire is difinitive)
      
4. Document everything you can -- your goal is to understand how the breach occured so that you can close that goal; you may well need help to do that and those people need details;
5. "Move" files to secured places, don't delete them until you are sure you won't need them any more
6. GET APPROPRIATE HELP -- if you know where the fault that allowed access lies, then contact their security arm:
   
   • http://drupal.org/node/101494 describes "send detailed report to security@drupal.org"
   • Lots further escalation for other layers on the stack
7. Return site to online mode only once you are sure you have both stopped the bleeding and stopped the possibility of more