Secure SQL Server configuration Pat Larkin Ward Solutions

Session Prerequisites Understanding of network security essentials Hands-on experience with Windows® 2000 Server or Windows Server™ 2003 Experience with Windows management tools Hands-on experience with SQL Server 2000 and management tools Level 300

Agenda Introduction Protecting the application layer Protecting SQL Server

Defense in Depth Using a layered approach:  Increases an attacker’s risk of detection  Reduces an attacker’s chance of success Policies, Procedures, & Awareness OS hardening, update management, authentication, HIDS Firewalls, VPN quarantine Guards, locks, tracking devices Network segments, IPSec, NIDS Application hardening, antivirus ACL, encryption User education Physical Security Perimeter Internal Network Host Application Data

Why Application Security Matters Perimeter defenses provide limited protection Many host-based defenses are not application specific Most modern attacks occur at the application layer

Why Data Security Matters Secure your data as the last line of defense Configure file permissions Configure data encryption  Protects the confidentiality of information when physical security is compromised

Application Server Best Practices Configure security on the base operating system Apply operating system and application service packs and patches Install or enable only those services that are required Application accounts should be assigned minimal permissions Apply defense-in-depth principles to increase protection Assign only those permissions needed to perform required tasks

Defense in Depth EfficiencyContinuity Performance Tuning SQL Server Policies Capacity Management Security Storage Management Hardware Upgrades Performance Monitoring Disaster Recovery Support Antivirus Event Monitoring Change Management Security Policies Firewall Issues SQL Server Policies AD Group Membership UPS Recovery Testing Availability Monitoring Availability Management Group PoliciesBackup

Agenda Introduction Protecting the application layer Protecting SQL Server

Basic Security Configuration Apply service packs and patches  Use MBSA to detect missing SQL updates  Use SQL Critical Update Kit Disable unused services  MSSQLSERVER (required)  SQLSERVERAGENT  MSSQLServerADHelper  Microsoft Search  Microsoft DTC

What MSBA typically checks on SQL Server Too many members of the sysadmin fixed server role. Granting of right to create CmdExec jobs to roles other than sysadmin. Blank or trivial passwords. Weak authentication mode. Excessive rights granted to the Administrators group Incorrect ACLs on SQL Server data directories. Plain-text sa password in setup files Excessive rights granted to the guest account. SQL Server running on a system that is also a domain controller. Improper configuration of the Everyone group, providing access to certain registry keys. Improper configuration of SQL Server service accounts. Missing service packs and security updates

Common Database Server Threats and Countermeasures SQL Server Browser Web App Unauthorized External Access SQL Injection Password Cracking Network Eavesdropping Network Vulnerabilities Failure to block SQL ports Configuration Vulnerabilities Over-privileged service account Week permissions No certificate Web App Vulnerabilities Over-privileged accounts Week input validation Internal Firewall Perimeter Firewall

Database Server Security Categories Network Operating System SQL Server Patches and Updates Shares Services Accounts Auditing and Logging Files and Directories Registry ProtocolsPorts SQL Server Security Database Objects Logins, Users, and Roles

Network Security Restrict SQL to TCP/IP Harden the TCP/IP stack Restrict ports

Operating System Security Isolate SQL from all other server roles Configure the SQL Server service account with the lowest possible permissions Delete or disable unused accounts Secure authentication traffic

Logins, Users, and Roles Use a strong system administrator (sa) password Remove the SQL guest user account Remove the BUILTIN\Administrators server login Do not grant permissions for the public role

Access & Permission Models

Alternate Model

Files, Directories, and Shares Use NTFS (EFS) & non system volumes Verify permissions on SQL Server installation directories Verify that Everyone group does not have permissions to SQL Server files Secure setup log files Secure or remove tools, utilities, and SDKs Remove unnecessary shares Restrict access to required shares Secure registry keys with ACLs

SQL Security Set authentication to Windows only If you must use SQL Server authentication, ensure that authentication traffic is encrypted

Authentication Modes

SQL Auditing Log all failed Windows login attempts Log successful and failed actions across the file system Enable SQL Server login auditing Enable SQL Server general auditing

Securing Database Objects Remove the sample databases Secure stored procedures Secure extended stored procedures Restrict cmdExec access to the sysadmin role

Using Views and Stored Procedures SQL queries may contain confidential information  Use stored procedures whenever possible  Use views instead of direct table access Implement security best practices for Web-based applications

Restrict Remote Administration Restrict number of Windows Administration accounts Restrict the tools  Internet services manager  Terminal Services  SQL Server Enterprise Manager – restrict to a single windows user Restrict the computers using IPSec

Securing Web Applications Validate all data input Secure authentication and authorization Secure sensitive data Use least-privileged process and service accounts Close all unneeded DB connections Configure auditing and logging Use structured exception handling

Knocking Down The Side Door //Three mistakes in this statement alone: SqlConnection conn = new SqlConnection(); conn.ConnectionString = "data source=PYN-SQL;" + "data source=PYN-SQL;" + "initial catalog=pubs;" + "initial catalog=pubs;" + "user id=sa;" + "user id=sa;" + "password=password;" + "password=password;" + "persist security info=True;“+ "persist security info=True;“+ "packet size=4096"; "packet size=4096";conn.Open(); //Don't do this at home folks: SQL Query Composition string strQuery; strQuery = "select * from Users where UserName = '" + username.Text + "' and Password ='" + "' and Password ='" + password.Text + "';"; Completely un- validated user input! Oh, that’s bad, not using DSNs Worse, privileged user… …with a lame password

But Wait It Gets Better int rowCount = ds.Tables["Users"].Rows.Count; if(rowCount > 0) // If we get back something... { //...we must be succesfully logged in Session["LoggedIn"] = true; // Store the username in a session variable Session["username"] = username.Text;... Label... private void Page_Load(object sender, System.EventArgs e) {... Username.Text = Session["username"].ToString(); } This is the user name from the form Which we cross-site script onto the page!

Top Ten Things to Protect SQL Server Install the most recent service pack Run MBSA Configure Windows authentication Isolate the server and back it up Check the sa password Limit privileges of SQL services Block ports at your firewall Use NTFS Remove setup files and sample databases Audit connections

Next Steps 1. Stay informed about security  Sign up for security bulletins:  Get the latest Microsoft security guidance: 2. Get additional security training  Find online and in-person training seminars:  Find a local CTEC for hands-on training:

For More Information Microsoft Security Site (all audiences)  TechNet Security Site (IT professionals)  MSDN Security Site (developers) 

Questions and Answers