Denial of Service? What is it, and how can we defend against it? - Executive Overview

I've been asked to write a higher level version of some of my blogs.  Apparently my writing is too technical... 

According to Prolexic (now part of Akamai), DDoS, or Distributed Denial of Service attacks are on the rise, and getting smarter. 

If you rely on an internet facing website or service to either bring in, or communicate with customers, there's a good chance that service will be disrupted or greatly impacted in the near future.

A Distributed Denial of Service attack is a method used by an individual or group that wishes to do harm against your company by essentially making your website inaccessible. New attack tools are readily available on the black market, and reports indicate that attack traffic is up 133% over this time last year.

By sending large quantities of traffic requests to your company website (tens of thousands of hits per second), the attackers basically overload the website's ability to respond and service legitimate customer requests.  If your website is down, you are not reaching customers, and not generating revenue.    Even a mild attack has the effect of slowing down your website to the point where customers may not want to use it. Corporate reputation may be at risk as a cause of such attack.

The primary way that businesses can and are protecting themselves against these DDoS attacks is through the use of Content Deliver Networks.  

(for a more technical overview, please see my blog on CDN: Content Delivery Networks in the Context of Security).

A Content Delivery Network, such as Akamai/Prolexic augments your corporate website service by mirroring your website through many webservers distributed globally on their own network.  Should a Distributed Denial of Service attack be launched against your website, the effect of that attack is spread across many, many servers. The result is a greatly reduced impact on the service provided to you customers. In most cases, the net slowdown is almost immeasurable.



 Introducing a CDN service to front your Critical Corporate websites not only makes sense, but will greatly enhance your Disaster Recovery and Business Continuity programme.

 Should you find your website under attack right now, please look into the following service from Akamai.

Emergency DDoS Protection Service to Stop a Cyber Attack

References:

• http://www.prolexic.com/knowledge-center-dos-and-ddos-attack-reports.html
• Content delivery networks: A primer of CDN providers and technology
• Techtarget.com: content delivery network (CDN) 
• How content delivery networks (CDNs) work 
• http://www.quora.com/Content-Delivery-Networks/How-does-Akamai-CDN-work 
• http://www.searchblog.asia/topics/seo/will-using-content-delivery-networks-affect-seo/ 
• http://serverfault.com/questions/46830/how-do-cdn-content-delivery-networks-server-work 
• http://mae.ucdavis.edu/dsouza/Classes/MAE298-S09/sc421.pdf
• Updated List Of Vendors In The Content Delivery and Transparent Caching Markets 
• To Speed Up The Web, EdgeCast Has Added Google PageSpeed Technology To Its CDN 

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

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