I saw a blog post by Robert Hensing talking about Microsoft's new GPS product and its very uncreative name. This is related to a conversation some co-workers and I were having today. We were trying to think of when Microsoft marketing had a really big success on the product front. Vista and Zune, which Robert talks about, aren't exactly catchy names. If you look at the original packaging for Zune, it was a real eye sore which didn't convey what a Zune was (brown and orange box colors didn't help). The robot for Windows Server 2008 is okay, but it doesn't make me want to go get a copy or even really hit a web page about it.
I know Apple has received a lot of press because their products have had great advertising campaigns. Think about the iPod campaign where you could see the folks dancing and they were listening to iPods and how they changed back and forth with the media types. But they chose upbeat music, folks who were able to convey having a good time, etc. That carried over to say, "Get an iPod and join in on the fun." Mazda has ZoomZoom. You get the idea.
Then I thought about the new SQL Server 2008 logo. It's nice, but it's not a homerun by any stretch. I think MVP Darren Gosbell has a better take with his kookaburra version of the logo.
Every so often I see a post in the forums where someone has stated they've used a Domain Admin level account to run the SQL Server service. The implications are that anyone who is a member of the sysadmin fixed server role is effectively a domain admin. That means if a developer is a member of this role within SQL Server, the developer can use SQL Server to execute with these rights. The same is the case of a SQL Server DBA in production. Typically DBAs don't have domain admin rights unless it's a small shop. But if SQL Server is configured to run under a service account that has such rights, the DBA effectively is as well. Not good.
In all but the rarest cases this is absolutely unnecessary. Truth be told, SQL Server doesn't even need administrative privileges over the server it's running on. Therefore, it certainly doesn't need Domain Admin rights. In security there is the Principle of Least Privilege. It's a simple concept: give only the rights needed to do the job and no more. This just doesn't apply to people, it also applies to service accounts. When it comes to SQL Server, this principle should be applied to the SQL Server service account just like any other.
How can you determine if your SQL Server is running under a Domain Admin account? First, determine what service account SQL Server is using. This can be done through SQL Server 2005 Configuration Manager (Figure 1) or SQL Server 2000 Enterprise Manager. You can also use the Services applet under Administrative Tools (Figure 2).
Figure 1:
Figure 2:
Once you know what the account is, check with your system or directory services administrator. If it's named [Domain]\Administrator, chances are likely that it is. If you have access to Active Directory Users and Computers, you can check the groups the service account is a member of (read access is all that's necessary and that's typically granted to all authenticated users in Active Directory). If you find the service account is a member of the Domain Admins group, do the research as to why. If there's a legitimate, unavoidable reason (and this should be extremely rare), seek to change the account immediately. This also applies to the SQL Server Agent service account.
Note: My snapshots are from a development laptop which isn't on a domain, hence the use of LocalSystem. Generally, though, LocalSystem isn't recommended and actually strongly suggested against. If this laptop had been on a domain, these accounts would be running under a local user account.
I recently purchased a Dell XPS M1530 laptop for use both for professional work (consulting & presentations) and ministry (mostly presentations). Yesterday, as I was at home recovering from a back injury, I noticed that some files were closing a little slower than I remembered. So naturally I checked the event logs and in the System event log I found:
The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume C:.
I'm wary, as would be expected, when I see this kind of error. Usually it's the first sign of a hard drive going bad. But apparently others have noticed it on a Dell and suspect it has to do with hibernation. Perhaps that's the case, as I've been using hibernation a lot lately when originally I didn't at all. If it is hibernation, not a big deal, because the system boots up just about as fast from a complete shutdown as it does from hibernation, so I'll stick with that. In any case, I opened up a support call with Dell and the first representative and we went through the SFC /SCANNOW and he instructed me on what they wanted to see to run on the pre-boot assessment diagnostics (which, if you hold down the Fn key at the Dell screen, the system will enter into). Because I would have to restart the system, and because of the size of memory and HD space I have, he suspended the ticket and I went about to run the checks. Several hours later, no errors reported on any of the hardware. The guy was professional, focused on the issue at hand, and gave the types of tips and reminders I would have expected (make sure you backup your important data frequently, etc.).
So I go back into chat and understandably get a different person. I re-explain the issue and he says he understands and then asks if he can use DellConnect to connect and remote in. I agree and in the process of starting it up realize it's just Citrix GoToAssist with a Dell interface slapped on top. No biggie. So I watch what he's doing. He immediately goes in and starts with trying to change the PageFile and the DEP settings and then goes to a web site where he was starting to download a Spyware Cleaner. I break in and ask basically, "What are you doing and what does this have to do with the main problem?" He replies back, "I wanted to increase your system performance." My response was, "Look, it says I have file system corruption, that's what the call was about, not about performance issues. The system performs just fine. Can we focus on the main issue?" The reply I get back is, "Ok, well, you can do this..." which is basically to reboot, hit F8, and select repair your computer. After that he terminated the call. I'm hoping I get a survey to fill out because I'll report that the second guy didn't focus on the issue at all. What a completely different response!
As far as fixing the issue, with no more expectations from Dell, I went into repair your computer and ran the CHKDSK C: /F and it had a few extended attributes that were corrupt (those aren't handled by the transactional processes of NTFS) and there were a few files that were orphaned from any indexes. The chkdsk fixed those and I immediately ran another chkdsk to see if there were any more errors that cropped up. With nothing else being reported I rebooted. I've kept an eye on things and I've even run a chkdsk in read-only mode this morning with no more issues. I typically keep everything backed up to 1 or more USB drives anyway, so if the system were to go south, I'd only lose what I was immediately working on. That's just a good practice, as Kimberly Tripp has blogged about. You never know when an unexpected failure is going to happen. So plan that it will at some point and take the precautions to ensure your loss is minimized.
The folks at attrition.org have been stalwarts in providing information to the security community for ages, it seems. I first discovered them via their defacement mirror, which they ceased maintaining long ago because site defacements became so common there was no point. About three years ago they began actively tracking data loss reports. Earlier this year they started to do a sign-off like they did with the defacement mirror, but the response from the community was so overwhelmingly positive towards the contribution attrition.org had made, they decided to keep it going.
If you've not checked out the mailing list, and you have anything to do with data security, you may want to. In addition to maintaining a mailing list, they also maintain an open source database of data loss incidents. It's a .CSV file, meaning it's easy to work with. When you look at who has been hit and the numbers, it's not pretty, but it is good information to know. It puts in perspective that anyone can be hit and therefore none of us should be complacent.
Andy Warren points to a TechNet article about Security by Obscurity and wanted me to post some notes. Let's start with the example they used.
Rename the Administrator account:
I agree with Roger's take. We intentionally rename the administrator account because it does stop the malware and scripts. We intentionally rename the administrator account because it allows us to alert easier. We see a hit against administrator, and we know 99% of the time it's not legitimate. That allows our reaction to be quicker.
This doesn't mitigate the need for strong passwords. They still must be there. And the argument that a GPO applies the same administrator rename is only partially true. If you segment your systems in different OUs or you use WMI filtering or you security groups to determine which computers can apply a GPO, you can have multiple GPOs with multiple renames.
What Security By Obscurity Gets You:
Security by obscurity gets you an advantage against automated scripts. Security by obscurity gets you a time delay against an attacker intending to break in. Depending on how the system is obscured (for instance, if you move the HTTP port, the attacker must do a port scan first... which, depending ont he environment, may be detectable). Security by obscurity can get you early notice. For instance, if you don't use administrator anywhere and you start getting audit failures against administrator, you know one of three possibilities is true:
Any of those three you want to know about.
Why It Isn't Where We Should Stop:
But security by obscurity doesn't absolve you of responsibility for taking all appropriate security measures. For instance, if you rename the administrator account but you still have a weak password, the account is still weak from anyone who can browse the system. Therefore, you still secure the password.
Let's apply this to SQL Server.
A script or the worms we've seen will not be able to get to your SQL Server. But assume you have a blank sa password (a complete reliance on security by obscurity). You've stopped the easy stuff. But then you've got that one internal guy who knows the sa password is blank. Even if he doesn't know the port on SQL Server, if he can access the server, he can try a port scan, such as with Nmap. Most of these tools (Nmap falls into this list) allow a very slow rate of fire, meaning they won't get picked up on alerting. Once he finds the port, he can get in. And if this server contains data that's worth some money, he can afford to wait until he finds the port. And then the guy gets in, gets the data, and likely you have no audit trail. Not good.
Therefore, certainly hide your systems; make 'em harder to find. But don't neglect the other aspects of security.
