Voice of the DBA

Category: Editorial

  • Default Credentials

    Years ago I got a call to help someone with a database. I walked over to their desk (when this was possible) and sat down. They asked me how they could get into a database they had been told about. I quickly realized this was an Oracle database and asked for credentials for SQL*Plus. This person didn’t have any, but I was able to log in with SYSTEM and MANAGER. This was a small department system of some sort, but it always struck me that the default credentials were available. Since then, every time I’ve encountered an Oracle database, I’ve tried those credentials. I’ve been amazed how often they worked, even for production systems.

    Recently there was a report that the Nissan corporation had some of their source code leaked. While I would prefer that the code running inside cars was open and widely examined, I was more dismayed that the leak was from an internal Git server with default credentials. Maybe even worse is the defaults are admin and admin, something that might not be hard to guess.

    I understand people make mistakes, and I do get that there are pressures people feel to get work done, but there isn’t a good excuse to stand up any server in production with default credentials, and I’d argue a VCS server is production. Even if you didn’t install the server and were just moving it to a new role, or you take over administration, you can’t leave default credentials around. You certainly can’t accept “admin” as a password in 2021.

    To me, this is grounds for termination. If nothing else, it’s certainly a reason to remove someone from a privileged position. Being this lax with security would worry me, and I don’t know that I could trust that you’d been careful with other parts of your job. If I encountered this, I would request that every other system under management be audited for improper admin accounts.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Improving Availability Groups

    Availability Groups (AG) were introduced in SQL Server 2012, with the idea that we could dramatically improve (and ease) the burden of dealing with high availability in SQL Server. At the time the (code named) HADRON technology seemed full of possibilities.  Since then, there have been some enhancements, but it seems that setting up and managing an AG, especially across subnets, isn’t as simple as Microsoft would have us believe.

    One of the problems with AGs is that there are non database resources (logins, jobs, etc.) that create dependencies. Working around the issues is a headache for many administrators, and it shouldn’t be. While there are some enhancements potentially coming, I don’t know what shape these will take or if they will make things easier.

    Some of my previous work as a DBA relied heavily on SQL Agent and jobs, neither of which are handled by AGs, or by plenty of other HA/DR technologies. Instead, administrators cobble things together, save scripts, and manually repair issues after failover. To me, this is one area that I’d hope Microsoft enhanced for AGs.

    Another area is the listener, which seems to be brittle. It works great, or it’s a nightmare to get working, without always an easy way to debug. I’d certainly welcome improvements here, including the ability for tooling to support multiple listeners easily.

    Many of you work with AGs now, and many more of you may in the future as the need for HA grows all the time for databases. Are there improvements you’d like to see in AGs, or any other SQL Server HA/DR technology? Feel free to leave a comment or submit something to Microsoft.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Security in the Aftermath

    Not too long ago was a very sad and embarrassing day for the US. The US capital was breached and rioters had hours inside without authorities. Ignoring the reasons and politics behind the event, think about the security of the building and systems after the criminals were removed from the building.

    Someone else brought up this point, which I think is fair. Can you trust any system in the building? Keyloggers, cameras, who knows what devices might have been planted. As a friend noted, anything with a plug should be thrown out. Who knows what might have been replaced or altered to create a security vulnerability.

    I haven’t had intruders in an office, but I have had to evacuate offices and returned to find unsecured systems. I’ve seen unlocked computers, when there were law enforcement or fire department staff walking around unsupervised. I doubt they did anything, and certainly never heard of any breach, but it is something to think about before you have to deal with the event.

    Have you thought about this or had to deal with this situation? Are you ready to audit systems and ensure nothing happened? Forget about spy devices, though those are certainly possibilities in this day of hot-plug USB keyboards, what about someone accessing information? If someone left a machine unlocked, would you think to check the history of the machine? Look at sites visited or emails sent? I don’t know I’ve ever thought about this, though in today’s world, this is something to consider. We are seeing some crazy types of attacks on systems, and I suspect it will continue to get worse.

    I learned a long time ago to lock my machine when I leave for any reason. A large group of administrators took delight in changing configurations, wallpaper, even sending embarrassing emails from unlocked machines to the group. After making a couple mistakes, it became a habit to lock a machine before you stood up for any reason.

    Most of us won’t deal with criminals walking around our office space, but we certainly should be careful and aware that unsupervised people around privileged systems is always a bad idea. I used to hate taking out the trash from a computer room I worked in, but I now appreciate that allowing cleaning staff into that space might not have been a good idea in a nuclear power plant.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Reassess Your Configuration

    It’s the start of a new year, and while it might feel like COVID-19 has us stuck back in March 2020, I hope that will start to fade as we move into the new year. Certainly our employers want to move forward, and I suspect that there is some hope that organizations will start to thrive in 2021.

    I saw a post from Kenneth Fisher recently that talked about an end of year, new year checklist. It’s a basic set of things that you might do as a type of review and cleanup of some of the instances and databases that you manage. Checking things like end of year processes and performing some review of potential items that might no longer be needed.

    In the past, I didn’t do this type of work at the end of the year, or even that often, but when there were slow times, I did have a list of things to periodically review. We had canned queries and reports to help us evaluate resources. Many were automated to ensure the data about systems was available if I had time.

    One area that I was check once or twice a year was the configuration, trying to determine if any hardware had changed, the workload had altered, or there were proactive configuration changes we could make. This might include removing unused security logins or turning off services that weren’t being used.

    Certainly I was always cognizant of the load that managing lots of databases can have on a DBA. Every additional database is a potential customer that can call or file a ticket. I couldn’t often remove any, but I did find ways to remove unused objects and archive data at times. Reducing resource usage often pays itself back over time, especially when the need for more storage arises, which was more of a battle than it needed to be.

    I might add one thing to Ken’s list. I would ensure that you should check on cloud resources that might not be used. One thing I see too often is that cloud resources are easy to spin up and leave up, even if they become unused. Finding a few of these might earn you some points with the people paying the bills.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.