How to stop rogue SQL servers?

I need some creative and as bullet-proof as possible ideas on how to stop rogue SQL servers from being installed and running on my internal network.
- Any SQL Server 2000 or MSDE on Windows 2000, XP or 2003 (servers and workstations).
- Limited to options only available to work in a pure native mode Windows 2000 domain.
- Ideas involving hardware devices such as firewalls, IDS systems, router/switch/port controls, etc. are really not an option on this solution, but side suggestions are always welcome.
- Any effective control mechanisms for allowing/disallowing it in an easily manageable way and consideration of known apps that require MSDE are helpful.
- One tough issue is that there are developers that have local Admin rights and that should be considered.
- Any solution that involves controlling the SQL services in Group Policy 'may' only get partial points as this has some limitations and workarounds. BUT if you have a really creative or bullet-proof method that goes along with it, then you could ring in all the points.

I'm eagerly awaiting a security guru to answer this!
Who is Participating?
PAQd, 500 points refunded.

Community Support Moderator
Rich RumbleSecurity SamuraiCommented:
So, what about port scanning? Is that out? What about turning on more event auditing, and using Snare to alert you of these types of things as well as lert you to other problems on your lan through the event logs? It can be considered IDS to some degree, but that's not all it does.

Stoppage is really a 3 parter, First, acceptable usage policy, should state that users/developers are not to install unapproved software such as this... second, you need to monitor to be sure that the acceptable usage is being followed, snare is great, and 3rd you may have to disallow certain exe's through AD.
Acceptable use: (and many many more great policies)
Software restriction GP's
BuzzbeeMeAuthor Commented:
Thanks richrumble for the reply.

We use port scanning for 1433, but that only identifies them, not stops them before they install it. However, I will investigate Snare further.
Event logs are problematic as we are a VERY large environment. We are in the process of getting an event log consolidation/monitoring system in place, but at present, its just not there yet. Also, it would be an 'after the fact' catch, not 'stopping' them.
We do have a paper policy in place and is about to be enforced at the absolute highest level to all employees, which, hence, is where the actual stopping and enforing starts to come in.
Group Policies...significant limitations so far..
- Software restrictions: Only works on XP/2003. We are going to use it, but we are vastly Win2k, which does not support this option.
- Resticting an .exe: This option is a user policy, not a computer policy. Even using a loopback policy to make it a computer policy, the problem is that it is expecting a user to launch it, not the 'Local System'. If SQL is using the 'Local System' to startup, the policy does nothing. It only works if the user actually attempts to run the exe, which normally, they wouldn't as it is a service.
As you can see there are some intracacies in doing this and I have some limitations of what works and what I can do.
Thanks for the suggestions and pease keep the ideas coming.
On-Demand: Securing Your Wi-Fi for Summer Travel

Traveling this summer?Check out our on-demand webinar to learn about the importance of Wi-Fi security and 3 easy measures you can start taking immediately to protect your private data while using public Wi-Fi. Follow us today to learn more!

Rich RumbleSecurity SamuraiCommented:
We are also very large, 5000+ users, 600+ servers. And snare was great for our purposes, but we've moved to GFI's SELM, which is far more expensive, but works just as well.

Programs like DeepFreeze are able to allow/disallow you to install program by using process locking, similar to what ZoneAlarm does when a new program want's access to the nic or to act as a server. 

BuzzbeeMeAuthor Commented:
I ended up using a few GPO's that disabled all SQL services and set the service permissions to only 'Domain Admins'. This ensured not even developers with Administrator rights could start the services.
For application servers, which have thier own OU, a 'Master' policy was created as noted above. For servers that were actually approved to run it, a lower-level policy was used to enable the services and set the correct permissions.
For workstations, which are in several OU's, a 'Master' policy was created at each level with the settings noted above. For those that were approved, we used a group filter from an approval list.
This all worked really well.
Rich RumbleSecurity SamuraiCommented:
Glad to hear you worked out the solution.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.