One of the biggest dangers of the sa account is that if attackers discover its password, they can access your SQL Server system. In mixed-authentication mode, SQL Server doesn't lock out users after a specified number of incorrect login attempts. Thus, an attacker can use a password-cracking tool to discover the sa account password. Even when you choose Windows authentication, you still need to set a strong password for the sa account (i.e., one that's at least 12 characters long and includes a combination of uppercase, lowercase, numerical, and ALT characters). Because with Windows authentication you can't use the sa account to log in to SQL Server, many administrators who use Windows authentication don't bother to set a password for sa. But if for any reason you switch from Windows to mixed authentication, the sa account password will be blank—and vulnerable to attack.
In the same vein, ASP and Visual Basic (VB) developers who realize that using the sa account for ADO connections isn't wise can still get into trouble. Instead of using sa, these developers create SQL Server logins and configure them with the appropriate level of permissions for accessing databases, tables, and other objects. But because their applications aren't using the sa account, these developers get a false sense of security and set a simple sa account password instead of creating an appropriately long, complex password. So although developers might correctly configure an application to use lower-privilege accounts, SQL Server might still be vulnerable to direct attack through the sa account.
Attack Mode
Attackers are familiar with the sa account's unique characteristics. Attackers can easily determine which authentication mode you're using as long as they can connect to the TCP port that SQL Server listens on. In SQL Server 2000 releases before Service Pack 3 (SP3), attackers have a quick, easy method for identifying SQL Server's listening port; they can query an unnamed service that I call the SQL Advertisement Service, which listens on UDP port 1434. This service has an unchecked buffer that the SQL Slammer worm exploited (SP3 fixes this vulnerability). When an attacker queries this service, SQL Server 2000 returns the names of all available SQL Server instances and the port that they're listening on. Attackers can also find available SQL Servers by using port-scanning tools that try to find servers that are using TCP port 1433, the default SQL Server listening port, or port 2433.
After attackers identify an available SQL Server by querying the Advertisement Service or scanning ports 1433 and 2433, they can easily figure out which authentication mode you're using. Attackers simply open Query Analyzer, enter the IP address of the SQL Server, type sa for the username, leave the password blank, and click OK. If the subsequent error message says Login failed for user 'sa,' the SQL Server is using mixed authentication. If the error message says Login failed for user 'sa'. Reason: Not associated with a trusted SQL Server connection, the SQL Server is using Windows authentication. Attackers typically attempt to access servers that return the first error message.
The attackers' next step is to try to determine the sa account's password. Many tools—including SQLdict at http://ntsecurity.nu/toolbox/sqldict and sqlbf at http://www.sqlsecurity.com/scripts.asp—are available for revealing the sa account's password through a dictionary attack or a brute-force attack. Security auditors use tools such as these to test the strength of SQL Server login passwords, but attackers also have easy access to the tools.
Password attacks work well because SQL Server lacks account-lockout capabilities. But the APIs that the cracking applications depend on to create logins and send them over your network usually incur enough performance overhead to make them less useful for an impatient attacker. However, Network Intelligence India has a utility called Forcesql (available at http://www.nii.co.in/research/tools.html) that creates the login and sends it over the network itself, avoiding the performance overhead. An attacker or auditor using this tool can specify a character set and password length for a brute-force attack. Forcesql can generate about 200 to 300 password guesses per second. During initial lab testing of Forcesql, I completed more than 1 million password attempts in 90 minutes. Because such tools are easy to obtain, DBAs and developers need to create sa passwords that are long and complex enough to dissuade attackers.
Protecting Your System
Let's look at secure password techniques and other steps you can take to provide additional security for your system in a mixed-authentication environment.
Set a strong sa password. You should use the sa account only when you can't use any other account for administrative purposes. This means you'll use the sa account rarely, so you can set the password for the maximum length. For example, SQL Server 2000 and 7.0 allow a 128-character password. If such a lengthy password seems impractical, you can use the first few sentences of a book or employee manual as a password so that the person who has sa permissions doesn't have to memorize the password. If you want to use a shorter password, you should still use at least 12 characters and include a combination of lowercase, uppercase, numeric, and (if possible) special ALT characters. Few brute-force tools can crack passwords that contain ALT characters such as © and ®. (For a list of available ALT characters, use the built-in Windows utility Character Map—charmap.exe.)
Audit logins. The cornerstone of proactive security administration is auditing. SQL Server lets you audit logins by using the Application log and by using SQL Server Profiler. The Application log has one significant shortcoming: SQL Server logs all login events, regardless of whether they succeed or fail, as Category (4) and Event ID 17055. Several other types of events also use this Category and Event ID combination. So unless you use an additional utility that can further parse the event-viewer logs to find event descriptions, you have the daunting task of reading every log entry to determine whether someone is trying to guess SQL Server logins. Also, the Application log doesn't record the connecting client's IP address for DBAs to use in tracking down attackers. Profiler can track failed login attempts in a more granular fashion, showing an administrator specific login failures, the account name a client used, and sometimes a hostname.
Proactively detect intruders. To compensate for the lack of a robust SQL Server logging mechanism, organizations should consider deploying an intrusion-detection system such as the open-source IDS Snort (available at http://www.snort.org). Snort logs date, time, and IP information for clients that connect to SQL Server, letting you easily see when someone is repeatedly trying to access your system. If you configure SQL Server to use the Windows Application Log for auditing events, consider using a syslog facility (such as those available from Kiwi Enterprises at http://www.kiwisyslog.com) to search through SQL Server auditing events and discover repeated access attempts. Many syslog tools are available for Windows servers.
Prev. page
1
[2]
3
next page 
