Network management Toolkit

Security wake-up call

Tags:
Port 1433,
Security,
Sa,
Slammer

Tim Landgrave Tech Republic

Published: 11 Feb 2003 10:46 GMT

On a Saturday morning in late January 2003, many system administrators woke up to cell phones and pagers alerting them to serious network problems with their servers. A worm targeting SQL Servers had hit company and commercial data centers around the world. In fact, a national bank's ATM network was brought to its knees, and a major carrier's airline reservation systems were totally shut down. The worm directly affected only machines with SQL Server installed, but the traffic generated by the worm made it almost impossible for other servers on the Internet to continue communicating with one another.

The worm, dubbed "SQL Slammer," attacked via a vulnerability discovered six months ago in SQL Server 2000 software from Microsoft. Microsoft had released a patch in the summer of 2002, but hundreds of IT managers hadn't yet installed the patch. This incident was similar to the Chinese worm event that took place two years ago. In that case, Microsoft had also issued a security patch to protect Web servers using its IIS software six months in advance of the attacks. Given the increasing focus on Internet security, how could an attack like this have happened again?

Keep your guard up
One reason is that IT managers have been focused on securing Web servers and firewalls, and these SQL Server attacks weren't even on the radar screen.

But in some cases, it's not even the IT managers who are to blame but the service providers that they use. Many of the systems affected by the worm weren't infected but were housed in data centers or colocation facilities that had other customers whose servers were infected. Because of the traffic generated by these infected servers, other machines couldn't get enough bandwidth to operate effectively.

SQL Server viruses typically infect machines with Internet connections using the standard 1433 port and default passwords. These worms use the default SQL Server system administrator account (sa) with an empty password to infect the system. The newly infected SQL Server then becomes an attacker, looking for other servers to infect.

Protecting the server is simple: Just change the password on your sa account to a strong one and block access to your SQL server from the public Internet.

Renewed vigilance
Security incidents like these should inspire you to have a sense of renewed vigilance in protecting your infrastructure. Take a hard look at SLAs signed with your data center or colocation provider to make sure that your partners are doing everything they can to ensure uptime. You should revisit the following five security actions.

Install the latest patches on your servers
Having the latest patches is especially important for servers that are directly connected to the Internet. Many IT managers won't install operating system or application server patches until they're able to do some testing first. Having worked with hundreds of customers who've spent thousands of hours testing these patches without any negative effects on their servers, I can confidently state that you stand a better chance of being infected with a virus than causing damage to your production machines by applying security patches.

Don't allow anyone to install servers with simple passwords
Many breaches occur because developers want to test systems with minimum amounts of security and therefore put in accounts with administrative privileges and blank or simple passwords (like "password"). When the systems go into production, these immature security schemes get propagated to the final application. In fact, I participated in a public presentation recently where the presenter was showing his production system. When he logged into the machine across the Internet, one of the attendees noticed that he accessed his SQL Database using the sa user ID and no password. In the middle of his presentation, all of his data "magically" disappeared. The attendee had logged into the presenter's SQL Server using the wireless connection in the conference center and had dropped all the tables from the database. Needless to say, it was quite embarrassing for the speaker and had a profoundly negative effect on the application's users.

Go to section: