Some wise configurations to make in your Drupal setup include:

1. Limiting the ability of anonymous users to create accounts. Account creation is the single greatest target of spammers and Google link jackers (people who will try and post links to their own sites from your own simply to promote their search engine rank). Allowing anonymous users to create accounts with no oversight or confirmation encourages the creation of bogus accounts by automated programs, otherwise known as bots. Attackers will look to create accounts in your Drupal site because by default Drupal distinguishes between two types of users: authenticated and unauthenticated users. If an unauthenticated (anonymous) user can create an account they can effectively elevate their own privileges.
2. Disallow anonymous content posting. You don't want anonymous users to be able to post content for reasons closely linked to #1 above. Without any stopgaps, bots will quickly find your site and flood it with bad content in an effort to parasitically host links to their own sites on yours. Anonymous users shouldn't be able to create content (including content or uploads) without some sort of check or verification.
3. Delete the PHP input type. Drupal, by default provides a number of different formats that users can utilize when entering data into web forms for things like content creation and comments. The three default formats are full HTML, filtered HTML and PHP. Filtered HTML should be used whenever possible. Filtered HTML will strip out any malicious HTML (such as javascript) to keep your site safe from cross site scripting (xss) and cross site request forgery (xsrf) attacks. The PHP input type is hardly ever used and therefor should be deleted entirely. With PHP input types users can write PHP directly into their content for the server to evaluate. This privilege is exactly what attackers search for, and if you aren't using this capability it's presence presents a much greater danger than help in your Drupal installation.
4. Disable use of PHP. Similar to number 3 above Drupal offers certain users the ability to input PHP code into web forms and then evaluates (or runs) that code as it presents content. This is a powerful, and rarely used, feature. Attackers, however, can make extremely effective use of PHP to compromise your web server. In general, because PHP is hardly ever used by Drupal administrators or content creators, privileges to use PHP should be disabled. If there is some reason to use PHP inputs then you can enable permissions until the PHP is crafted, then disable them again.
5. Limit upload file types. Drupal allows users to define the types of files that can be uploaded to the server. Attackers will try to upload PHP code to execute on your server, or perhaps executable malware or other dynamic content. By disallowing scripting languages or executables from being uploaded you cut off this avenue of attack.
6. Restrict error reporting. Occasionally Drupal code will result in errors. In these cases, by default, the complete debugging text about the error will be logged in Drupal's internal error log, and displayed on the screen for users. Except in development environments where programmers are the users, this information is completely useless to end users. Furthermore, the information contained in debugging messages could leak critical configuration details to attackers (known as an information disclosure vulnerability). Because Drupal system administrators can view error messages in the internal logs there is no reason to display errors to the screen. Turn off screen reporting of errors whenever possible to close this disclosure vulnerability.
7. Create groups to manage permissions. Many permissions can be misused to exploit a Drupal site. Try to grant permissions in the most restrictive way possible to limit users exclusively to permissions they they will be required to use. Use extreme care with permissions like 'administer content types' and any permission that allows the use of PHP.
8. Disable the uid 1 account created when Drupal is installed.
9. Delete all the root level .txt files since they're not needed and can be used to fingerprint the site
10. Enable the Syslog module so that Drupal Watchdog messages also get logged to the standard syslog
11. Limit input formats so that users can't utilize applet, object, iframe, script, or other tags that could be used to insert malicious content.  Audit the node_revisions table to ensure that no malicious content is present.