eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
While the Blaster worm and Sobig virus garnered the lions share of attention and fear last year, 2003 began with a worm that caused many headaches for administrators of Microsoft Corp.s SQL Server 2000. The SQL Slammer worm, which exploited a known and patched hole in SQL Server 2000, crashed servers and brought networks to their knees.
In multiple tests held recently at eWEEK Labs, an unpatched SQL Server system became infected with SQL Slammer in less than 10 minutes. However (and amazingly), a year after SQL Slammer first struck, there are still many vulnerable and unpatched SQL Server systems on the Internet.
|
Clearly, there are many people who havent gotten the message when it comes to patching and securing SQL Server 2000.
Compounding the trouble is the fact that MSDE 2000 (Microsoft SQL Server 2000 Desktop Engine) is also vulnerable to SQL Slammer and is often installed as part of third-party applications.
There is no reason for this problem to be as bad as it still is. While it takes vigilance to stay aware of your potential danger spots and to know where all your SQL Server and MSDE implementations are, securing SQL Server itself isnt rocket science.
Next page: Steps you can take to lock down SQL Server
Steps you can take
to lock down SQL Server”>
The first and most obvious step in security for SQL Server is to stay up-to-date with the service packs for SQL Server 2000. All the most recent packs include fixes for the problems that cause SQL Slammer, as well as for other potential security problems.
In addition, we recommend that when dealing with a new or unpatched SQL Server system, IT managers take that system offline or put it on a closed network. Given how quickly Slammer can strike, any IT staff is bound to end up with an infected system while patching a new system.
This will also provide an opportunity to do offline testing of the patch to ensure it doesnt adversely affect your applications.
Outside of SQL Slammer, a poorly secured SQL Server implementation can make it easy for malicious attackers to crack applications and databases and access sensitive information. One of the most common mistakes is poor or nonexistent authorization security. Weve been stunned the numerous times weve seen a SQL Server system with a blank sa (system administrator) password. We recommend using a strong, regularly changed sa password and, if applications permit, using Windows authentication.
Another common-sense step to take in securing SQL Server is to block the ports on which it listens for connections—namely, TCP port 1433 and User Datagram Protocol port 1434. If the systems that need to connect to SQL Server are the only ones that can connect to it, you will have more protection against unknown problems that may arise.
Next page: Web resources for SQL Server security
Web resources for SQL
Server security”> Of course, practicing good security in general will help a great deal in securing SQL Server. Using vulnerability-checking applications and patch management tools will help IT managers find vulnerable systems, especially embedded MSDE engines.
In addition, any applications that attach to the SQL Server database must be secure against common holes and exploits. If your applications are full of holes, securing SQL Server wont help.
Finally, its important to educate yourself about SQL Server. There are excellent books available that go into great detail about configuring and securing SQL Server and Windows server systems.
Its also a good idea to frequently check Microsoft developer boards on SQL Server, where one can often find information on late-breaking problems as well as advanced tweaks and settings that can make SQL Server deployments more secure.
Labs Director Jim Rapoza can be reached at [email protected]
|