On the way to work today, I remembered an occasion where a team member who'd left the company had been stockpiling 1U rackmount servers in storage. He'd reimaged each server with a common image (each had different passwords, though). I had a listing of passwords for each server, but the listed password for one particular server wasn't working and we needed to get access to that machine. I couldn't just reimage the machine since, even though it shared a common image, it was prepped for deployment to a certain location and was configured for that specific site. While I had a copy of the site-specific information, I just did not have the time to reimage the machine and reconfigure it...I saved that as a "last resort" option.
After a bit of research, was able to log in successfully.
I knew the BIOS wasn't locked down, so I went into the BIOS and enabled booting from CDROM. I had a copy of a Linux CD which I put into the CDROM tray. I then power-cycled the system. I was able to use the live-CD to boot up the box. I mounted the drive within the system and removed the encrypted password within /etc/passwd using 'vipw'. I then shut the box down, removed the live-CD, then started the system. I was immediately given a shell. I then reset the password to what was on the passwords list for that particular system then finished the pre-deployment steps.
This is why I love Linux. There's always an option. I could NOT do this with one of the backup Windows servers we had. That case was similar: the system was a cold backup and was racked but powered down...it was a new system with a new image but customized for a specific role...it had yet to be used, though. The password that we had for the device was apparently incorrect. I even tried to crack the SAM file...that didn't work and I eventually had to reinstall (not reimage) Windows Server (forgot which version) onto the system again. What made this much worse was that there wasn't an original cloning image to use, as well as the fact that the previous engineer hadn't maintained directions on how he configured the device. So I had to use the trial-and-error method. I eventually configured the OS properly and installed and configured the proper software (it was a CA eTrust AV server). The whole time, the lead client was pestering, badgering, and being overly hostile.
In another case, another contractor had left the company. He'd been administering a Nessus server that he installed on top of OpenBSD. This contractor chose OpenBSD and was comfortable with working within a terminal session (as was I). And really, the box didn't really have an abundance of resources anyways, so it was probably more robust without the GUI enabled. I understood something of OpenBSD and was aware of how to conduct scans and how to view/store the scan results. I even had a cron job running that would conduct the scans during maintenance windows. Everything was working fine. The same client lead couldn't operate the system because his *nix skills were seriously lacking. Instead of asking for help/guidance, he directed another contractor to wipe the machine and install Red Hat with the GUI enabled so that he could operate the machine. Data was not backed up. The scanning data as well as configuration man-hours were wasted.
Another time, I was working a deployment issue where client remote hands were my remote hands/eyes. They'd received our Snort sensor that we'd imaged, customized, and configured and had just finished racking and powering it up. The remote hands did not know anything of how to operate within a terminal session. I walked him through the process, spelling out the commands he needed to type. The problem? We built the machine and while testing it before we shipped, had logged into the machine via SSH. When the machine was at the remote location, I could not establish an SSH session because the host key had changed. In order for me to regain access, the remote hands had to remove the existing host key that was tied to the IP of my work machine...the host key resided on the Snort sensor that I was trying to log into. What made me feel good was that one of the clients was logged into the bridge call and was listening. After the call, she praised me for my knowledge of guiding the remote hands through the whole process without ever being able to view what was on his screen. She also commented on how I guided him in what to type. In this case, I could care less how much they were paying me (which wasn't really all that much)...I was happy that I was able to be of assistance and value. That was payment enough. That was one of the few bright days in working with that particular organization. I soon took a dignified stance and left that contract. To this day, I will not recommend any person I know to work at that particular location without giving them ample warning.
But the main reason for this post is to share that I love *nix (and why)!
No comments:
Post a Comment