Securing SQL Server: Protecting Your Database from Attackers

Read an Excerpt

SECURING SQL SERVER

SYNGRESS

Chapter One

INFORMATION IN THIS CHAPTER

* Securing the Network

* Public IP Addresses versus Private IP Addresses

* Accessing SQL Server from Home

* Physical Security

* Social Engineering

* Finding the Instances

* Testing the Network Security

Securing the Network

You may think that talking about the network is a strange way to start off an SQL Server book, but the network, specifically the perimeter of your network, is the way that external threats will be coming to attack your SQL Server. A poorly defended network will therefore give an attacker an easier time to attack your network than if the network were properly secured. In larger companies the network design and lockdown would be under the control of the network administration and network security departments. However, in smaller companies, you may not have either a network security department or a network administration department. You may not even have a full time database administrator (DBA) or systems administrator. In a typical larger company, developers do not have to worry about the network design and setup as this is handled by the network operations team. However, in smaller companies the software developer may be asked to design or even configure the network along with the web servers or application servers.

No matter your position within the company, it is always a good idea to have a working understanding of the other technologies in play within IT. This will allow for decisions to be made in a more thorough manner by looking at the entire infrastructure instead of examining how the process needs to be completed with just one piece of technology or another.

Network Firewalls

At your network parameter will be your network's firewall. This will probably be a network device in its own right or a software component within your network's main router to the Internet. This firewall is designed to block and allow traffic based on a set of rules that have been loaded into its configuration. Some routers do not have a firewall software package loaded into them. In the case of network devices that don't have a built-in firewall, you'll want to use the Access Control List (ACL) of the device to control what port connections are allowed through the network router. With regard to blocking access through a device, an ACL can be just as effective as a full firewall. However, a full firewall will give you additional protections that the ACL cannot, such as providing you with Distributed Denial of Service (DDoS) protection. DDoS protection is used to keep a network up and running in the event that the network comes under a DDoS attack. A DDoS attack occurs when a group of computers, usually zombie computers owned by unsuspecting people being controlled by a hacker, send large numbers of requests to a specific website or network in an attempt to bring the network offline. DDoS protection is handled by specific network devices that are configured to look for patterns in the network traffic that is coming into the network, and block network traffic from reaching the destination if the network traffic appears to be part of a DDoS attack.

Typically, your firewall would sit between the public Internet and your border router. A border router is the device that sits at the edge, or border, of a network between the company's network and the Internet Service Providers (ISP) network. This allows the firewall to protect not only the internal network from the Internet, but also the border router from the Internet. A typical network diagram is shown in Figure 1.1 and will be the network design that is referenced throughout this chapter. In this sample network design, the Internet cloud is shown in the upper left. Connected to that is the firewall device that protects the network. Connected to the firewall is the network router that allows network traffic to flow from the public network, which uses an IP Address network range of 204.245.12.1-204.245.12.254, to the internal network, which uses an IP Address network range of 192.168.0.1-192.168.0. 254. Because the firewall sits on the front side of the network, you'll be granting access through the firewall to the public IP Addresses that your company was issued, in this case 204.245.12.0. If you placed the router on the internal side, then you would grant rights to the internal 192.168.0.1 network.

When you first fire up the hardware firewall, typically all access through the firewall is allowed. It is up to you to shut down the network access that you want blocked. In a typical network firewall the configuration will be written into a file, although some newer devices may present you with a web interface that you can use to configure them. In either case, the configuration of the network firewall will be read line by line from the configuration and processed in that order, opening and closing ports in the firewall. Like access to objects within an SQL Server, the firewall is configured via a series of GRANTs and DENYs. While in SQL Server DENY always overrides a GRANT, typically within a firewall you will want to instruct the firewall to close all ports and then open only the needed ports (keeping in mind that every network administrator has a different technique for writing firewall rule sets).

Typically the first line that you would see in your configuration of your firewall or ACL would be similar to "extended permit ip any any." This would then grant all access from all networks, in this case the public Internet, to the 204.245.12.0 network no matter what TCP port was used. We would then want to follow this with a line similar to "permit tcp 204.245.12.0 255.255.255.0 any." This line then allows all computers within our public IP space access to everything on the public Internet on any TCP network port. You can see these firewall rules from a sample configuration file in the following sample code.

When a user or a server accesses the Internet, the firewall will see them as coming from an IP Address on the 204.245.12.0 network. This is because the router will use Network Address Translation (NAT) so that the computers on your internal network can use private IPs to access the public Internet. Because of this NAT setup, all the computers that access the network will usually report as coming from the same public IP Address. You can verify this by using several computers in your network and browsing to the website www.whatismyip.com. All the computers in your office will more than likely report back the same public IP Address.

Now that the router is configured to block everyone on the Internet from accessing the public IP Addresses, the next step is to allow our customers to access our web server so that they can access our website and purchase the product that is being offered. In order to do this, a decision needs to be made as to which network topology design will be used. The three most common topology design options are: (1) web server on the public internet network, (2) web server on the internal side of the network, and (3) web server in the Demilitarized Zone.

Web Server on the Public Internet Network

You can connect the web server to a network switch between the firewall and the router, and then configure the server with a public IP Address, as shown in Figure 1.2.

Web Server on the Internal side of the Network

You can connect the web server to the network switch on the internal side of the network and configure NAT to allow people to connect to a public IP Address and have the router send that traffic to the internal IP Address of the web server, as shown in Figure 1.1. By comparing Figure 1.1 and Figure 1.2 you can see that the web server has been moved from the outside network to the internal network.

Web Server in the Demilitarized Zone

You can create a DMZ (Demilitarized Zone) network that will contain the web server in a separate network from your internal network and that is separate from your public network, and then use NAT to allow Internet users to access the server within the DMZ network as shown in Figure 1.3.

No matter which of these three network designs you use, the users from the Internet will access your public website via a public IP Address. In this example the IP Address 204.245.12.2 will be used as the public IP Address of the web server. If you were to use option #1 shown above, you would simply enter this Network Address into the Windows Network Control panel (or if you were using Linux or Unix the appropriate file for your specific distribution, typically /etc/network/interfaces or something similar). If you were to use option #2, you would use an IP Address from the 192.168.0.0 network for the web server, then configure the NAT on the router to redirect traffic from the 204.245.12.2 public IP Address to the private IP Address that you chose. If you were to use option #3, you would use an IP Address from the 192.168.2.0 subnet for the web server, then configure NAT on the router to direct traffic from the 204.245.12.2 IP Address to the correct 192.168.2.0 subnet.

After you have selected the network design to use you will need to configure the firewall to allow access to the web server. You will want to restrict the ports that the firewall allows access through to just the specific ports that are used by a web server, in this case ports 80 for normal HTTP traffic, and port 443 for encrypted HTTPS traffic. This would be done by using a line similar to "permit tcp any host 204.245.12.2 eq www". This line tells the firewall to allow traffic on ports 80 from any Internet IP Address to 204.245.12.2. The IP addresses shown in the examples in this chapter are shown in Table 1.1.

If you didn't block the network traffic, then anyone on the public Internet would have access to all the TCP ports on the server. This includes the web server, but also the file shares if this is a Windows server, the database if there is a database installed on the server, and any other software that is running on the server. Attackers would exploit a configuration such as this and attempt to break into the server by attacking known weaknesses in those services. These weaknesses could include known bugs in the Windows File Share protocol, or a brute force attack against the database server. Once the attackers had broken in to the server, they could install just about any software that they wished to on the server, capturing your customer information, configuring your web server to install malware on your customers' computers, install software to turn your server into a zombie bot, have it send out SPAM or launch a DDoS attack against another website, and so on.

Server Firewalls

In addition to the network firewalls described within this chapter, the firewall on the Windows Operating System should also be enabled and configured to allow just the needed network connections. By installing and configuring the Windows firewall to block all unexpected network connections, if any unauthorized software is installed on the server that software won't be able to be contacted. Ideally, any outbound network connections that aren't expected should also be blocked so that any software installed can't phone home. While legitimate software phoning home isn't necessarily a problem, unauthorized software shouldn't be allowed to phone home as it may be passing confidential data to the controller or the server may be part of a bot-net.

Windows Firewall Inbound Rules

The most secure Windows firewall configuration option is to allow the needed inbound network connections such as TCP (Transmission Control Protocal) connections to the SQL (Structured Query Language) Server, UDP (User Datagram Protocol) connections to the SQL Server Browser, and SMB (Server Message Block) connections to the server's network file shares. Most SQL Servers wouldn't be running any other network software that would need to be contacted from outside the SQL Server's Windows Operating System. It is also usually a good idea to allow ICMP (Internet Control Message Protocol) packets through the firewall so that things like ping will work against the server, as this is a good way to see if the server has completed rebooting.

(Continues...)

---

Excerpted from SECURING SQL SERVER by DENNY CHERRY Copyright © 2011 by Elsevier Inc.. Excerpted by permission of SYNGRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Read More