Voice of the DBA

Tag: security

  • The Need for Tape

    This editorial was originally published on Mar 26, 2009. It is being re-run as Steve is away at DevConnections.

    One of our SQLServerCentral authors sent me this post, which I found to be pretty amazing. Apparently hackers broke into a backup server at WebHostingTalk, which is a community for hosting providers to discuss issues. They deleted backups first, and then moved on to deleting tables from the database.  It resulted in some downtime, and then a restore of an old copy of their database prior to trying to restore more recent copies. More information from the admin is here.

    Now that’s just malicious and nasty.

    Hopefully this wasn’t an inside job, though I could see that as a possibility. For a service like this, that just provides a place for a community, let’s people interact and talk, this is just vandalism. It serves no purpose. It’s likely no one even knows it was “M@M@sB0Y” or some other hacker, so there’s no fame, and it disrupts people who just want to converse with colleagues.

    I’d hate to think about this happening here. We have lots, and lots of posts from people all over the world, and while it wouldn’t kill us, it would really annoy many people that have volunteered their valuable time to help others by losing their work. We definitely need to make sure we don’t have an issue here.

    I see two takeaways from this incident for most DBAs and administrators. First be sure that your backup servers are just as secure as your production ones. There is production data in the forum of backup files here, and you should be providing as much security for them, and perhaps more, as on other servers. Don’t treat these servers lightly.

    Second I think this shows that there’s a need for tape backups, or some type of non-linked backup. A tape grabs the files from your server, completely separately from the SQL Server (or other application). It is a pull link, and it’s not obvious from the source server where these files have gone. That’s good in that it prevents some type of attack on the main server from propagating on. Most people use a push from their server to a remote device as part of the backup process. That’s OK, but it provides an easy link for someone to attack the backup server from the main one.

    And one more benefit of tape? Usually they’re rotated out, so even if a hacker or insider knows how to get to the backup system, without physical access they can’t touch your tape.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Versions of Disaster

    Today’s editorial was originally released on Jan 13, 2009. It is being re-run as Steve is on vacation.

    I wrote about versioning of old software recently and how I had to restore an old version of SQL Server in response to a lawsuit. We had some challenges because the backup file that we had was from years before and we weren’t sure which version of SQL Server we needed. I forget how we finally determined which service pack was needed, perhaps we read master somehow to get a build.

    In any case, when you apply patches or change how SQL Server functions, you can change the way that code is executed or even the results that might be returned to an application. You would hope that code would break and error out rather than return different results than you expect.

    Since many of us patch servers when Service Packs come out, or when we find a hot fix we need, and we are constantly deploying and changing code, do we pay enough attention to the server version as we make these deployments? I started thinking about this after the last editorial and I think that we often take it for granted that we can easily recreate our environments.

    Consider what would happen in the event of a disaster. Suppose that one of your server instances, any particular instance, died and you had to go back to a backup of the database, would you know what version of SQL Server is needed? Do you know what version each of your instances is using right now?

    In some ways this makes me think that only installing RTM and Service Pack versions in your production environment is a good idea. It’s easier to track things if you keep all your instances within a very narrow band of versions, and the worst case would be attempting a restore on RTM, then SP1, then SP2, etc. until you hit the correct version. Imagine now if you had to work through the various builds on my build list.

    I used to think that I’d want to keep current on my patches. In one large environment, we were actually pretty good about deploying patches to hundreds of instances inside a month, so we always had a large percentage of our servers, and usually all the critical servers, at the same patch level. However if a disaster had occurred within the month, we wouldn’t necessarily have been sure of what versions were installed.

    I really don’t have a great recommendation on how to handle this other than build some automated system that tracks the current build number on a daily basis, perhaps even putting it in each database. At least then you’ll have it handy in the event of a disaster.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.mevio.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Lost in the Noise

    I’m glad I have well water. Not that it protects me, but it provides some insulation in the event that the local water company’s systems were hacked and unclean water released. That hacking could happen, and the person in this piece speculates it is happening after a water authority honeypot attracted hackers from all over the world. It’s scary to think how the world may change when any individual, as well as any country, could attack our digital systems. It means security is more and more important all the time.

    As I read the article, I looked for a positive in the experiment. Was there something to take away from this research? The thing I thought of was the way in which hacker traffic was drawn to this system. Not that hackers were not also investigating other systems, but if honeypots existed, perhaps in enough places, would the additional targets provide more security?

    That’s an interesting idea. What if you had CRM/Sales/Inventory systems that were available for port scans, and hacks, but didn’t connect to banking systems and had test/dummy data? Would a few of these provide some security by luring hackers into spending their resources on these systems instead of real systems? What if you had 4 or 5 instances of SQL Server, probably Express, responding to port scans and providing a relatively easy target. You could monitor these systems, and perhaps be more prepared for real attacks when they occur.

    I have long felt that we can’t completely eliminate threats and secure our systems from any unauthorized access. What might be worse is that we may not be able to separate real queries from fake ones. What we need is better monitoring and awareness of the traffic to our systems. Perhaps if we had honeypots that we could monitor, we would be able to draw some hacking traffic, identify users that were unauthorized and then use that information to better protect, or audit, our real systems.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 15.5MB) feed

    MP4 iPod Video ( 18.3MB) feed

    MP3 Audio ( 3.8MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Physical Security

    Think your office is secure? You have guards during the day checking badges, you have key card systems to control and audit access and alarms set at night. You don’t worry if you have various system names or passwords scribbled on scratch paper. After all, who would target your office?

    You never know. With the large number of people working in technology, there are bound to be a few people with less than prefect morals. The turnover of employees in technology can be high, and it might not be as easy to recognize an outsider as you think.  Even in companies that only have 50 or so employees, it’s easy to assume the person you see in the company is new hire, contractor, or other individual that has reason to be there.

    Especially if that person gets into your locked server room because they’ve hacked the alarm or key card system. At the Black Hat conference, hackers demonstrated how they can get past many alarm systems and talked about their methods for cloning RFID cards by walking near someone. The fact that these technologies are available, relatively cheap, and can be implemented by people that have some knowledge of the systems means we have to be more careful than ever about the physical security of our systems.

    Be aware of the authorized users that can physically access systems. Ensure that you don’t have passwords or other critical information easily available, and encrypt your systems. Even if someone breaks into your data center, they won’t want to spend a lot of time there. If someone can easily get information, or copy files, they will. Adding a few security hurdles to bypass might mean the difference between keeping control of your data and losing it.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 14.4MB) feed

    MP4 iPod Video ( 17.5MB) feed

    MP3 Audio ( 3.5MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center