SQL Server Magazine

The SQL slammer Internet worm that appeared in 2003 caused a lot of damage and resulted in lost productivity for many IT shops. Consider the virulent means by which SQL slammer was able to propagate itself: By scanning the network for other SQL Server instances through well-documented means, SQL slammer simply copied itself from one SQL Server to the next. You can prevent this sort of propagation by using SQLPing 3.0 to scan your network for new and possibly misconfigured or unprotected SQL Server and Microsoft SQL Server Desktop Engine (MSDE) installations so that you can properly secure them.

SQLPing uses a wide variety of methods, such as both active and passive scans, to detect SQL Server and MSDE instances, including multiple SQL Server instances installed on a single physical server. It also has the ability to challenge passwords (to ensure that SQL Server users aren’t using weak passwords) through “brute force” probes.

When invoking SQLPing, you can choose to perform an active scan on a range of IP addresses or to scan all the IP addresses in a specified text file, as shown in Web Figure 1 (www.sqlmag.com, InstantDoc ID 97668). If you choose to perform an IP address range scan, SQLPing also includes a couple of buttons on the Scan tab that let you perform a DNS lookup for the starting point of the range scan and/or fill in the last octet of the Class C scan.

SQLPing uses two input files, userlist.txt and password. txt. Userlist.txt contains a list of all the user IDs that you want SQLPing to attempt to challenge. Password.txt contains a list of all the passwords that you want to challenge against each of the users identified in the userlist.txt file. The SQLPing .zip file contains samples of the userlist .txt and password.txt files for demonstration purposes. Although you can use the sample files, you’re encouraged to replace the sample values with your custom dictionaries of users and passwords.

When defining your scan, you can choose whether SQLPing will use all available techniques to scan for SQL Server instances or a subset of the techniques available by selecting the appropriate check boxes on the Options tab, as shown in Web Figure 2. SQLPing includes six active scanning techniques and two passive scanning techniques.

You can enable or disable most aspects of the scan under General Options on the Options tab. You can also choose to enable a Debug Log (and specify the path and name of the debug log file), which provides additional information about the performance of SQLPing. Note that you can specify alternate login credentials on the Options tab if you need to access specific domains on the network.

When you’re ready to run a scan, simply click the Scan button on the Scan tab. SQLPing will return a list of all the SQL Server instances it finds. You can save the entire report (or just the IP address list) by clicking File, Save.

SQLPing requires the Microsoft .NET Framework 2.0. Also, due to .NET policy restrictions on most computers, you should execute the SQLPing 3.0.exe program from a local drive; otherwise, you risk losing partial functionality.

Note that there’s an alpha release of a command-line version of SQLPing now available. This release includes only the high-level switches included in the GUI version of SQLPing. The benefit of the command-line version is that you can automate SQLPing scans and reporting as part of a DTS or SQL Server Integration Services job. InstantDoc ID 97668

Author’s Note: I need your help finding free tools for SQL Server! If you’re aware of a SQL Server tool or script that’s written and supported by a SQL Server enthusiast and would be useful to the SQL Server community, please email me at kevin.kline@quest.com. The tool or script must be free, non-commercial, and receive continuing support.

End of Article