10 things to secure your DNS server

Note: I wrote this in 2013, and it's still as relevant to DDOS discussions today as it was then.

 In light of the recent Spamhaus DNS "the Internet is falling!" FUD , I thought I would write an article on the 10 best things you can do to secure your DNS Infrastructure.

 (Plain English explanation of the Spamhaus DDOS attack)

What is DNS? - Go ! Read!  I'm not going to explain it here!

The method, and misconfiguration issue behind the Spamhaus DNS attack is not new, nor should we be dealing with it at this point in time. There have been many previous such attacks, and many reports on how to remediate against such types of attacks, yet here we are...

There is a multitude of free and/or Open Source DNS Server implementations available on the Internet.  The two most significant of which are BIND, which serves most of the Internet, including the worlds largest Governments and Companies, and Microsoft DNS, which also has a large installed base in the Corporate Intranet world.   Any and all of these are capable of contributing to an extensive Distributed Denial of Service attack if not properly configured and secured.

What problems can a misconfigured  DNS server have?
The most prevalent DNS issue is around "Open Resolvers", where a DNS server on the Internet is configured to allow recursive DNS resolution outside of the Domains for which it provides Authority .  This can lead to the types of recursive amplification DDOS attacks that impacted Spamhaus.

Cache Poisoning is another type of Denial of Service attack against , where the attacker attempts to flood a caching DNS server with fake requests, to slow down it's services. While doing this, the attacker simultaneously spoofs the authoritative DNS response for the domain they want to attack, in the hope that their spoofed request will get to the DNS Cache quicker than the true one.  Once spoofed, all traffic to that domain will be redirected to the new injected address.




http://dns.measurement-factory.com/surveys/201010/
Distribution of name server software versions

"we estimate that there are as many as 11,920,500 open resolvers on the Internet.

The total number of open resolvers on the Internet appears to be decreasing with time, but it is still quite high. We urge developers and manufacturers to read and implement RFC 5625, DNS Proxy Implementation Guidelines.^[4] Administrators should read and implement RFC 5358, Preventing Use of Recursive Nameservers in Reflector Attacks.^[5] "

10 things to secure your DNS server

1. Implement Firewall rules for DNS Security- Your firewalls should only allow DNS query traffic on UDP/TCP port 53.  Additionally, it should only accept zone transfer requests from known DNS systems. (see item 7)
2.  Registered Black Lists.  Subscribe to - and block addresses from - these maintained lists of known malicious IP addresses. This can be done either by the firewall or on the DNS server itself.
3. Segregate Internal and External DNS Servers - Keep your Internal DNS and associated private IP space inside of your firewall.  Use a DNS Proxy for DNS queries to the Internet. Do not advertise your private IP space at all on your External DNS servers. (See item 6) 
4. Close Open Resolvers   on your External (Internet facing) DNS server. (for BIND) (for Microsoft)  There is no reason for your  Internet facing DNS to be recursive.    Internal DNS should be configured to allow recursion to Internal addresses only.  http://dns.measurement-factory.com/surveys/openresolvers.html
5. Keep DNS Server Version Up to date and patched - Maintain regular patching on your DNS server. Any vulnerability that is discovered in the DNS software will quickly be exploited.
6. Disable version banner - Service banners are a sure way to advertise what vulnerabilities your system may have. Turn them off.
7. Restrict zone transfers - Only allow KNOWN DNS servers to request a Zone Transfer.  In BIND, you can restrict zone transfers using either (or both!) DNS Access Control Lists or TSIG - transaction Signatures. Here's how Microsoft recommends such restriction. 
8. Configure Rate Limiting - Rate limiting is a relatively new feature in most DNS systems, but allows you to control DNS traffic flow so as to not get into a Denial of Service position.
9. Do not Run DNS service as "root" or "Administrator" - Run the service under it's own non-privileged account.
10. Run BIND in a chroot jail. - This separates the DNS process and it's associated file systems and access from the rest of the Operating System it is running upon.   If DNS *does* get compromised, they will not be able to escalate privileges to the rest of the server.

 NOTE:  I understand that I've not brought up DNSSEC.  I'll save that for a future discussion on it's own.

Resources:

http://www.ietf.org/rfc/rfc1035.txt -- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
http://www.ietf.org/rfc/rfc5358.txt -- Preventing Use of Recursive Nameservers in Reflector Attacks
http://www.ietf.org/rfc/rfc1918.txt -- Address Allocation for Private Internets
http://www.ietf.org/rfc/rfc5625.txt -- DNS Proxy Implementation Guidelines
http://www.ietf.org/rfc/rfc2845.txt -- Secret Key Transaction Authentication for DNS (TSIG)
http://www.zytrax.com/books/dns/ch4/
http://dns.measurement-factory.com/surveys/sum1.html
The Continuing Denial of Service Threat Posed by DNS Recursion (v2.0)
http://en.wikipedia.org/wiki/Paul_Mockapetris
http://en.wikipedia.org/wiki/Jon_Postel
http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
http://blog.isc2.org/isc2_blog/2008/08/securing-dns-se.html

NIST: How to Secure a Domain Name Server (DNS)
www.cert.org/archive/pdf/dns.pdf - Cricket Liu
http://spi.unob.cz/old/last/ostatni/proceed2001.pdf#page=70
http://www.prolexic.com/gad/2012-q4-attack-report.html
http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
http://www.redbarn.org/dns/ratelimits
http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
http://www.sans.org/reading_room/whitepapers/dns/securing-dns-zone-transfer_868
http://www.zytrax.com/books/dns/ch7/xfer.html

Develop an Enterprise Secure Coding Programme

So lets start out by saying that I have no intent on teaching you how to code, and you probably wouldn't want to learn from me anyway!

This particular rant is about developing your overall 

Enterprise Secure Coding Programme 

regardless of your size.

More than ever before, we must be diligent about our Application Development practices. In today's fast paced, highly competitive Internet environment, it is expected that your Corporate Applications not only look and feel "modern", but are also built to work on a multitude of platforms.  Gone are the days when you can write an application to "work best" on Internet Explorer.  Apps must present a consistent user experience across various browsers and platforms.  This diversity of endpoint systems increases the potential for vulnerable code to be exposed.  

Coding Securely needs to be a Corporate Culture, supported from the Top down. Every layer of employee has a role in this practice. An application built from the ground up on the principles discussed below will spend a lot less time in "vulnerability management", and a lot more time in building and releasing features.


I'm going to structure this discussion by addressing the responsibilities of each Business Role at a high level, then break each one of these down, further on.

Responsibilities of the CIO:

• Adopt, Publish, and Test a Corporate Coding Best Practice
• Base your Application Development Practice on your Business Core Competencies
• Adopt an Existing Application Framework
• Adopt and support Revision Control Religiously
• Ensure that a trusted Application Testing Methodology is in place.

Responsibilities of the Application Development Team Lead:

• Review, comment, and test the Corporate Coding Best Practice
• Develop and publish a Standard Naming Convention for Coding
• Ensure that your team is only developing to your Business Core Competencies
• Use an Existing Application Framework 
• Use Revision Control Religiously
• Maintain Reusable Code Libraries
• Understand and implement Release Planning
• Do not support reinventing anything
• Support the Corporate Application Testing Methodology

Responsibilities of the Developer:

• Read and understand the Corporate Coding Best Practice
• Print out the Coding Best Practice stick it on your refrigerator door!
• Understand what your Business Core Competencies are... Write code for THAT!
• Use an Existing Application Framework  
• Use Revision Control  Religiously
• Do Not reinvent anything
• Participate in the trusted Application Testing Methodology

Responsibilities of the Quality Control and Test Team:

• Ensure that the Corporate Coding Best Practice is being followed
• Enforce Revision Control
• Conduct Peer Code Review
• Participate in the trusted Application Testing Methodology
• Validate Security Controls through Application Security Testing
• Adopt and manage to a  Release Life Cycle

Coding Best Practices:
First of all, download and read the following!
(Then print it out, stick it on your fridge, and read it every morning!)
https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

A coding best practice is a set of rules or procedures that one follows to create legible, well documented application code that improves the quality of the application and provides for better maintenance.  Code should be clearly written using a standard naming convention for object or variable names, routine or module names, and table/field names.  Comments should be descriptive and short.

• Input Validation: - ensure all input in forms are type,length, and context validated.
• Output Encoding: - ensure that all output requests to your backend follow the rules
• Authentication and Password Management: - ensure corporate standards are met
• Session Management: - carefully manage,secure, and log user sessions
• Access Control: - ensure "Least Privilege Principle" is adhered to
• Cryptographic Practices: - use industry-tested and accepted standards and algorithms
• Error Handling and Logging: - ensure logs are auditable, traceable, and of high intergrity
• Data Protection: - ensure sensitive data is protected both in motion and at rest.
• System Configuration: - ensure that you "harden" your application as well as the OS it resides on
• Database Security: - protect your back end. Again ensure "Least Privilege Principle" is used
• File Management: - misconfiguration in could reveal confidential information about access credentials
• Memory Management: - ensure that memory that is allocated is protected, and subsequently freed 

Business Core Competencies:

Base your Application Development Practice on your your Business Core Competencies. By this I mean that if your company produces Widgets, then your Core Compency is in the mass production and sale of Widgets. Your developers should be spending the bulk of their effort in writing code to strengthen the sale of Wigets.

If they are developing "application frameworks" or writing "authentication" code, they are not doing you a service. There have been decades of collaborative prior art created that follow standards and have been rigorously tested.

Unless you are in the business of developing either of these... Don't.

Glad I got THAT off my chest.

Release Planning:

A software release life cycle is the sum of the phases an application goes through from its initial development, through testing, to release, and back to development for feature updates, and bug fixes.  

Application Framework:

Depending on what language you are developing in, there are many existing established Application Frameworks.   An application Framework is a library of software that has been developed to take care of the tedious tasks of managing input/processing/output  for various target systems.

Many current frameworks use the Model-View-Controller architecture to segment and manage their application code.

An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two. -- ConnellyBarnes

• Model - This is your Business Logic. Workflow, Database 
• View - This is your Presentation Logic
• Controller - This is your Application Logic

Reusable Code Libraries:
Where possible, reuse  functional code modules both within and application, as well as between applications. Maintain these functional modules in a library where Business Units can share and improve.
(See "Do not reinvent the wheel" Below)

To achieve success the keys are to:

1. Understand the architecture of the original code to identify the components, boundaries, and interfaces
2. Determine what is potentially reusable
3. Estimate the time to reuse versus rebuild the components
4. Make a decision on a component by component basis on what to reuse and how to reuse -no change, minor update, major update

 

Application Testing Methodologies:

Any application being developed must go through a series of testing regimes and criteria to be considered ready for production.  Typical testing includes:

• Usability testing: - validates that an application is designed to make tasks easier
• User acceptance testing - make sure your application meets the expectations of the user
• Performance testing - does the application perform well under various loads
• Stress testing - To determine the maximum performance limits of an application
• Scalability testing -  how adaptable is the application to changes in software and hardware
• Load testing - To get an idea of how the application behaves under a heavy load
• Security testing 
• Static- Static testing involves doing a static code analysis to check for any vulnerabilities
• Dynamic - run the app to see if the response is as expected for the associated request
• Functional testing - ensures that individual functions are working well
• Interface testing - ensures that individual components are connected properly 

Do Not Reinvent the Wheel:
Reinvent the Wheel Often According to O'Reilly's 97 Things Every Programmer should know...  Their arguement is as follows:

"Reinventing the wheel is not just an exercise in where to place code constructs: It is how to get an intimate knowledge of the inner workings of various components that already exist. Do you know how memory managers work? Virtual paging? Could you implement these yourself? How about double-linked lists? Dynamic array classes? ODBC clients? Could you write a graphical user interface that works like a popular one you know and like? Can you create your own web-browser widgets? Do you know when to write a multiplexed system versus a multi-threaded one?....."

Which is great if you are coding your own project on your own time, if you are a student, or researcher, or if you are in fact reinventing code within the context of your Business Core Competencies to identify and fix a deficiency.   However, if you are a paid developer, and simply want to rewrite a new framework or module because you believe you can do it better... you are not doing your Company a service.  Companies work on a Time to Market mentality.  By utilizing trusted existing frameworks and Open Standards, you can get your application developed, tested, and published quickly.

Resources:

First of all, download and read the following! 
(Then print it out, stick it on your fridge, and read it every morning!)
https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

Microsoft: MSDN: Coding Techniques and Programming Practices
http://net.tutsplus.com/tutorials/html-css-techniques/top-15-best-practices-for-writing-super-readable-code/
Tips for Secure Session Management
OWASP: Session Management Cheat Sheet

Best practices for data encryption

https://www.owasp.org/index.php/Category:OWASP_CLASP_Project
W3C: Mobile Web Application Best Practices
isc2.org: Application Development Best Practices
Model View Controller explained
IBM: DeveloperWorks: Reusable Code Libraries
O'Reilly: Reinvent the Wheel Often
IBM: Developerworks: Web Application Testing
Forbes: The Key To Great Web Software Is A Consistent, Intuitive User Experience
http://www.marketingtechblog.com/html5-user-experience/
 https://wiki.appcelerator.org/display/guides/Supporting+Multiple+Platforms+in+a+Single+Codebase

Should We Embrace an Enterprise Architecture Framework?

 With Great thanks to  Roger Sessions - ObjectWatch, Inc.

Through the mid 1980s and 90s, businesses realized that IT systems were becoming more and more complex, and more and more expensive. Vendors used differing standards, integration was difficult at best, and impossible most of the time. 

To add gas to the fire, by the time these IT systems were built, they no longer aligned with Business Requirements.

Out of this requirement for aligning Business Needs to IT Architecture and implementation, while keeping costs in line, came the field of Enterprise Architecture.

    As Defined succinctly by S R Balasubramanian in Enterprise architecture demystified:

"Issues that we are faced with

Management and users often express their dissatisfaction with the IT systems and we feel the need of addressing their concern. The common refrain that we hear is as follows:

i) IT systems have become unmanageably complex and increasingly costly to maintain.

ii) IT systems are hindering the organization’s ability to respond to current, and future, market conditions in a timely and cost-effective manner.

iii) Mission-critical information (provided by IT) is consistently out-of-date and/ or just plain wrong.

iv) A culture of distrust is developing between the business and technology sides of the organization."

As in most diciplines, they needed standards and guidelines to work to, and one of the first Enterprise Architecture Frameworks developed was the Zachman Framework.

 

The Zachman Framework  in it's original form was quite straight forward, and assigned roles, criteria, and decisions to the  questions:

 "Why, How, What, Who, Where, When" 

for each phase of an architecture, through "Contextual, Conceptual, Logical, Physical, and Detailed". 

This is commonly referred to as a "taxonomy" rather than a Framework but has laid the ground for all methodologies to come. 

 V3.0 of the Zachman Framework was introduced in 2011.

Over the past 30 some years, a number of Archtectural Frameworks have come and gone. Many were split and morphed into newer frameworks.  Federal Governments have developed their own, and large consulting organizations have done likewise.  Today, there are three frameworks that stand out among Enterprise adopters.

Department of Defense Architecture Framework (DODAF)

 "The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries."

The Gartner Enterprise Architecture Framework and Practice 

Gartner's Enterprise Architecture Framework (Formerly Meta) is more appropriately described as a "Practice" that encompases the Zachman Taxonomy with the TOGAF process and provides it as a service to large Enterprises.

  

The Open Group Architecture Framework (TOGAF)

Based closely on a previous framework, The US Department of Defence's TAFIM, TOGAF  is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency.  

 It is often referred to as "a process more than a framework", however has garnered wide adoption.

According to many who have assessed and evaluated these various "Frameworks" there is no single clear "winner".   They are complimentary pieces of the overall puzzle.

 

So, in conclusion...

 

The concept of adopting An Enterprise Architecture Framework is quite logical. As in adopting ANY Standards based process (Incident Management, Security Management, Application Development, Financial and Resource Management, etc...) one must understand the accepted frameworks, and analyse against your corporate culture and processes to 1) Chose a framework that best integrates with your existing environment, and 2) Define a roadmap to adoption.

 

As described above, although there are many Enterprise Architectural Frameworks established, none of them completely provides for an end to end process.

 

Enterprise Architecture as a practice, should embrace the Taxonomy of  Zachman, and adopt the Processes described in either TOGAF or DODAF depending on your particular Line of Business.

Definition of terms as per  IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems

• architect—One whose responsibility is the design of an architecture and the creation of an architectural description
• architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description
• architectural description—A collection of products (artifacts) to document an architecture
• architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like
• architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture
• architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description
• architectural taxonomy—A methodology for organizing and categorizing architectural artifacts
• architecture—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution
• enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise

Resources:


http://en.wikipedia.org/wiki/Enterprise_architecture_framework
http://www.slideshare.net/JWBurget/what-is-an-architectural-framework
Understanding and applying the Open Group Architecture Framework - TOGAF
Microsoft MSDN: A Comparison of the Top Four Enterprise-Architecture Methodologies
Objectwatch: Comparison of the Top Four Enterprise Architecture Methodologies
Welcome to TOGAF® Version 9.1 "Enterprise Edition"
TOGAF 9.1 Online Book
Canadian Department of National Defence (DNDAF)
The Best Enterprise Architecture: “Less is More”

Enterprise Architecture Methodologies and Comparisons

A Comparison of the Five Major Enterprise Architecture Methodologies: 2012

Enterprise architecture demystified

Gartner: Assessment of Enterprise Architecture Tool Capabilities

The Oracle Enterprise Architecture Framework

Securing your Database: 101

Regardless of whether you are running your SQL database (Yes, I know... I should be calling them Relational Databases) on Windows, UNIX, or Linux, the threats and vulnerabilities are very similar.

There are many SQL database vendors on the market. The fact that they need to function in a similar manner based on the SQL standards, makes them vulnerable to similar types of attacks.  These attacks can be initiated locally on the SQL server, or as far away as a client's Web Browser.

Database Vendors: (Comparison of relational database management systems)

Microsoft MSSQL, Oracle, Sybase, IBM DB2, MySQL, PostGreSQL, Informix

Below, I will outline some of the typical threats and misconfigurations that could endanger your SQL database. After each threat/misconfiguration, you will find some of the remediation strategies that can be used to reduce each risk.


Typical Threats

• SQL injection - A SQL Injection is a hacking technique which attempts to pass unauthorized SQL commands through a web application with the intent of having them executed by the SQL server.
• require SQL be constructed using parameterized queries, preventing SQL injection attacks by differentiating code from data.
• require Web Inputs be sanitized and validated - cast type and length.
• install Intrusion Detection/Prevention software and configure it to log and alert!
• do not provide SQL error or warning messages to the public
• limit database privileges

• Network eavesdropping - Network Eavesdropping consists of capturing data packets on the network inline with the intenet of capturing passwords, session information, or confidential data.
• require all communications between Webserver and Database Server be SSL/TLS encrypted.
• also require all communications between developers/administrators workstations and database server be SSL/TLS encrypted 
• Unauthorized server access - Unauthorized server access can be related to poorly configured or patched systems, or improper management of account privileges.
• ensure that database server and all connecting web and app servers upstream are patched in a timely fashion.
• ensure that all unused accounts, services, and features are disabled
• employ "Least Privilege Principle"
• use local firewall to restrict source systems
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!!  Review and Alert!  (I can't tell you how important custom logging/alerting is!)
• Password cracking - Password Cracking is the exercise of attempting to recover passwords from a file or network stream using various methods such as a dictionary attack.
• use complex passwords
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!! Review and Alert! (Did I mention how important this is?)
•  
• Denial of Service attack - An extension of the SQL Injection, a SQL Denial of Service attack will use any search forms available on your website to get your SQL database to execute a number of long running and CPU intensive queries so that the site becomes unusable to other users.
• install and configure Intrusion Detection/Prevention on database/web/app servers.
• LOG!!! Review and Alert! (Ok... this is important! Really!)

Typical mis-configurations 

• Default, Blank & Weak Username/Password  - As in any computer system, Database password controls are critical in setting and maintaining security of the database.  Default passwords must be changed upon installation. Corporate Password Standards should be maintained for all accounts.
• Excessive User & Group Privilege - Employ both Principle of Least Privilege and Segregation of Duties between Administrative, Application, and User accounts.   
• Unpatched Databases/Operating Systems - Database software, like the Operating System, is an integral part of your overall system security. Failing to patch in a timely fashion based on the vendor's recommendations places you in a state of higher risk.
• Unnecessary Enabled Database/Operating System Features - Any user/service account, feature, or service, installed on a system, that is enabled but not used, is a potential vector for attack.  If you do not need an account,  feature, or service in your production database, turn it off or better yet, remove it.
• Unencrypted sensitive data – at rest and in motion Todays servers have aqequate resources to negate any arguement around encryption/decryption performance. Any sensitive data that resides within the database should be encrypted.  I'm not saying encrypt entire tables or databases, unless required by compliance, but sensitive fields (Social Insurance Numbers, financial information, etc..) should be encrypted. Many SQL Vendors now also provide Transparent Data Encryption for full tables or Databases. Also ensure that any communications to and from the SQL server uses SSL/TLS encryption to prevent eavesdropping.
• Failure to configure audit and transaction logging - Properly configured, audit and transaction logs will allow you to identify abnormal or malicious traffic to your server. If coupled with Intrusion Detection/Prevention software, will be able to alert and/or remediate the intrustion immediately.
• Location of SQL Database server/data - During installation, ensure that the DB software and Databases are on a separate drive/volume from the operationg system. This allows you to provide greater protection to the storage volume without adversely impacting the underlying OS. 

And finally:  On UNIX Systems..... USE A CHROOT JAIL!

A chroot provides a sandboxed environment to install a critical service that "looks like" the host operating system.  It has a file structure similar to the host, and has copies of all the files and libraries required to run the application, but is logically segregated from the operating system it is hosted on. 

A properly configured chroot environment will prevent privilege escalation from the hosted application to the hosting operating system. What happens in chroot, stays in chroot!




Reference Material:


Default  SA accounts: (these need to be disabled or renamed once installation is complete)

Database	Admin Account Name	Admin Database
MSSQL	sa	master
Oracle	sys, system	dba_users
DB2	dasusr1
MySQL	root	mysql
PostGreSQL	postgres	pg_shadow
Sybase	sa, sccadmin	master

Default TCP ports: (firewalls should restrict access on this port to only servers/workstations authorized to communicate with the DB server)

Database	Ports Used
MSSQL	TCP 1433
Oracle	TCP 1521
DB2	TCP 3700
MySQL	TCP 3306
PostGreSQL	TCP 1433
Sybase	TCP 4200

Vulnerapedia! - Extremely nice matrix tool for Vulnerability Attacks/Controls/Threat Agents

databasesecurity.com

How to Build a Chroot Environment in CentOS

Best Practices for UNIX chroot() Operations
Increasing Security With Chroot Jails

Microsoft MSDN: Improving Web Application Security: Threats and Countermeasures
Secure Your MSSQL Server Database
Tips For Securing Your Database Server: MSSQL 2008 Transparent Data Encryption
MySQL: Reference Manual - Security Guidelines
MySQL SQL Injection Cheat Sheet
Symantec: Securing MySQL: step-by-step
IBM Developerworks: Total security in a PostgreSQL database
Security-Enhanced PostgreSQL (SE-PostgreSQL)
Securing PostgreSQL From External Attack
Oracle® Database 2 day Security Guide
Oracle Security Checklist
Oracle 11g Security - Those Pesky Predefined Accounts
Application Security Inc. - Hack-proofing DB2
Securing Your Data Assets Using Sybase® IQ Advanced Security Option

Top Ten Database Security Threats
The 10 Most Common Database Vulnerabilities
Threat and Vulnerability Matrix (Database Engine)
Tackling the network eavesdropping risk
Dark Reading: Five Ways To Stop Mass SQL Injection Attacks
Default Credentials: Low-hanging Fruit in the Enterprise
The Simplest Security: A Guide To Better Password Practices
Database Risk in 2011