I'm helping a customer with an exposed MSSQL 2005 server. They will not budge on a firewall or VPN solution... and there logs are full of signs of attacks.
What can be done to protect a exposed SQL 2005 Server without additional hardware?
By exposed I mean if you point SSMS at the public IP with the right credentials you are connected.
One cheap trick is to move the listening port off the default 1433. Clients can connect using the explicit port syntax, like tcp:74.125.19.104,12345 if the port is 12345. This eliminates the vast majority of bots scanning 1433 for sa,blank vulnerability. This of course does not solve the company from the other responsibilities involved: strong password policies, recycle passwords, monitor logs for suspicious activities etc etc.
Another thing they should consider is implement DirectAccess. DA eliminates most if not all of old VPN solutions drawbacks and companies scared by the Helpdesk costs of VPN should seriously consider DA instead.
And finally, there is the obvious question why do they need TDS access from the internet? Knowing what is the requirement, we may recommend alternative, less dangerous, solutions.
(That public IP belongs to Google, so the edit probably wasn't necessary)
The best thing you can do to secure a SQL server of any stripe is to whitelist the hosts that are allowed to connect to it, and to make sure to run as few other services as possible on that machine.
Another good practice is to severely restrict the access possible from the web side. If the web app is only allowed to run a few dozen stored procedures, then there are practically no attack vectors from an exploited website. On the other hand, if it can run arbitrary queries, then you're going to have problems.
Never run a webserver on your database machine: that's a huge, unnecessary attack vector that should be avoided whenever possible. Webservers and webservices are very often exploited. If your database is attached to the same machine, then it is far more likely to be taken down as well.
The easiest way to achieve all of this (without adding any new hardware) is to enable IPSEC, and tunnel requests from your web server to your database server. Here is a basic IPSEC tutorial.
If you have to have them on the same server, you can get a little security by only allowing local connections, but that's no help if your website gets exploited.
To disable remote connections, go to Server->Properties->Connections and uncheck "Allow Remote Connections to this Server".
Configure an IPSEC policy that permits connections to the SQL Server ports based on a whitelist of IP addresses/ranges, as previously mentioned. That means the OS will bear the burden of ignoring the traffic (which is why the network devices are obviously preferred). Make sure the firewall is up to protect all of the OS ports, especially those related to RPC, SMB, etc. Make sure the IPSEC policy ONLY allows connection to the SQL Server port. You shouldn't need to open a port for the SQL Browser Service (udp/1434).
If you can, alter the port SQL Server is listening on (probably tcp/1433) to some other port (make sure the IPSEC policy accomodates). If it's not on a well-known port, especially if it's a higher port, that will stop most of the scans against the system. The users will just need to know to connect via server,port instead of just server.
Slightly old, but still has some good information. MSDN chapter on Securing Your Database Server. http://msdn.microsoft.com/en-us/library/Aa302434
You could also purchase a software firewall, such as Zone Alarm or Outpost.
I'd strongly consider cutting all ties with a company that insists on putting their DB on the net without any form of IPSec, firewalling, or private connections. I hope they at least use some form of encryption.
It's a major liability waiting to happen; possibly a lawsuit or criminal negligence (depending on the data involved).
