Remove BOL from PROD boxes
-
Recently, an IS auditor came to me asking me to remove BOL from all Production SQL Server boxes.
He said by leaving BOL on a PROD box would expose vulnerability to malicious attackers. His justification is according to
Improving Web Application Security: Threats and Countermeasures
Chapter 18 - Securing your database server, by Microsoft, J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
URL : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh18.asp
I have been using BOL in PROD without any problem and to me it is helpful to have BOL for quick reference in PROD.
I really need somone to comment on this. Anyone pls advice.
-
The auditor's request makes sense when you look at it from the perspective of, "Is it needed for the production application to run?" In that context, Books Online is unnecessary. While it may be helpful, in reality how often are you operating from the console? That's the key question. If the majority of your access is remote (say, from your workstation) then that's where BOL should be.
And he's right to say that it does expose a vulnerability to malicious hackers. There have been Microsoft alerts on the help functionality (both Windows 2000 and 2003), but it's not an easy one to exploit... at least not if you're being as safe as you possibly can be. With SQL Server 2005 and the ability of the Books Online to do on-line lookups that's not as true as it once was because, thinking like an attacker, if I can poison your DNS server so you hit my server instead of the Microsoft documentation site, I can potentially get you to execute malicious code.
With that said, it's not a general practice of mine to remove BOL (or not install it to begin with), but I certainly see the logic in it.
K. Brian Kelley
@kbriankelley -
I rarely operate directly from the server console, but if I am it's likely to be in the middle of a crisis. If I need BOL and can't find it, that auditor better not drop in and ask how things are going.
-
All documented concerns aside, the auditor needs an education in the 'reality' of what a DBA does. The vast majority of the time one operates remotely from a desktop or via and RDP connection. But in selected, albeit rare, instances ("crisis mode") at the server console they need tools immediately at hand and BOL is one of them <period>. If the logic to remove BOL from the SQL Server is valid then the same logical argument may be made about QA, EM and OSQL.
Besides, SQL Servers are supposed to be in 'secure' networks (no outside access) or for servers that neet external conenctivity behind firewalls with a DMZ and other such things. In a proper network if a hacker got as far into the network to be able to get to the SQL Server he probably would not even need BOL anyway !
If it's just a documentation thing, well just about any hacker has acouple of choices to get BOL for themselves ...
- Evaluation copies of SQL Server
- Developer copies of SQL Server
- 'cracked' copies of SQL Server
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
It's not a documentation thing... it's the fact that Books Online uses Windows Help and is a known target... typically in a certain location (default of C:\Program Files\Microsoft SQL Server\80\Tools\Books for SQL Server 2000, for instance), etc. Chances are the SQL Server service account is going to have access to write files in that directory even if it can't write files where the typical Windows help directory is. Therefore, if I can get one of the help files replaced, and at a later time a DBA (who likely has admin rights) accesses it and mine is malicious, *BAM* and I've just initiated a compromise of the box with said rights.
How do you get the file there without infiltrating the network? By coming through an Internet facing web app, for instance. You may be to come through in such a way to cause SQL Server to write the file (use of xp_cmdshell comes to mind but it's not the only way... think sp_OA stored procedures and file scripting objects) and the attacker can place an exploit without ever modifying the data. Therefore, it *looks* like the attacker hasn't been there> Or maybe you've found out the attacker has penetrated the web app, perhaps you consider the web server compromised but since there aren't any obvious changes to the data, you believe the SQL Server to be safe....
Stuff like that. In other words, it's a means of dropping an exploit, albeit through a blended threat.
K. Brian Kelley
@kbriankelley -
Infiltration via the web application is a separate security issue to be dealt with (SQL injection or whatever other means). I feel that one has to balance the ROI vs. the 'risk'. In this case ROI is the precious time in getting a database back up and 'risk' is how many SQL servers have been affected by this specific exploit to date. My guess is that a DBA in 'crisis' mode at the console has happened quite a few more times than a a 'hack' to a secure SQL Server via BOL ... well my 2 cents are up now ... have a great day !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
True, but a justification can be made that Books Online can be accessed, even in IE enhanced security mode on Windows Server 2003 by dropping msdn.microsoft.com in as an approved site and navigating to the SQL Server Developer Center. So you do have an option, even in crisis mode, if BOL isn't installed locally.
K. Brian Kelley
@kbriankelley -
If I do need to remove BOL, how do I remove BOL after SQL Server installation?
I tried loaded back the installation CD and choose "Upgrade, remove and add components...." from the wizard. It seem like it will un-install everythings. Can somebody confirm this?
-
You can certainly remove the shortcut from the Start menu. Also, you could remove the files from wherever BOL installed. The default is the C:\Program Files\Microsoft SQL Server\80\Tools\Books directory. Keep in mind that there have been several upgrades to Books Online and that's where it typically locates the files. That would certainly remove the functionality that your auditor is concerned about. Of course, as with anything, test this in a non-production environment to make sure it doesn't break anything before trying to implement in production.
K. Brian Kelley
@kbriankelley
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply