Monthly Archives: January 2018

The HumbleLab: Desk of Death – Build a PXE Boot DBAN Station using pfSense and CentOS

I am become Death, destroyer of data.

Data sanitation is a required albeit tedious part of being a Systems Administrator. Last week I noticed that we had quite a few old machines piling up around our office and finding myself with a few spare hours I decided to see if I could speed up the process of scrubbing their hard drives using the ubiquitous Derik’s Boot and Nuke (DBAN). An important note, the mathematics and mechanics of using disks scrubbing software is actually fairly complex, especially when Solid State Drives are involved. My recommendation to you is to check with your security team to make sure your method of disk scrubbing is sufficient. Deguassing and physical destruction using an NSA approved methodology may be the only approved method for certain types of organizations. If you don’t have a security team or a regulatory compliance scheme that you have to comply with that specifies what your media disposal standards are the NIST standards are great place to start.

Disclaimers out of the way, now onto the fun stuff. Here’s what the old system looked like: A help desk tech would boot a CD, load DBAN into memory, select the drive/s to be wiped and then press Enter. This took a few minutes in addition to the time it took to setup the old workstation with power, a keyboard and a monitor. Here’s what I wanted: Plug in a monitor, keyboard and a network cable, turn the computer on, Press F12, pick Network Boot and move on.

To do this I setup an isolated VM on my lab (The HumbleLab) to run a TFTP service in conjunction with the DHCP services already offered by pfSense. Using an old workstation would of also worked just fine if you didn’t have an existing lab setup.

1. Install CentOS and configure networking

You will need to get a minimal install of CentOS setup. There are plenty of guides out there but this one is pretty nice. There’s always the official Red Hat documentation too. Configure a static IP address, fire off a quick su -c yum update to update your system and that should be enough to get you going. I had two physical NICs in my Hyper-V hosts so I dedicated one to my “DBAN” network, created a External Virtual Network with it and added a vNIC connected to that virtual switch to my new CentOS DBAN server.

2. Install and configure the TFTP service

Now we need to get our SYSLINUX bootloaders installed and a TFTP service setup. Lets install both and copy the SYSLINUX bootloaders into the tftpboot path.

Create a pxelinux.cfg directory along with a default configuration file.

Fire up your favorite text editor and edit the newly created configuration file:

Make sure that clients can pull the resulting files from the tftpboot directory:

Last but not least go ahead and start the TFTP service. You could choose to enable the service so it starts automatically but I personally like to start and stop it at will as a kind of weak safety check since it does automatically boot DBAN without user intervention.

 

3. Create a new interface and DHCP scope in pfSense

Unfortunately I lost my screenshots here so we’ll have to just go by feel. You will need to perform the following steps:

  • Add a new vNIC to your pfSesne VM that is connected to your DBAN External Virtual Network.
  • Use the pfSense web interface to assign the new vNIC as an interface.
  • Create a corresponding DHCP scope for your DBAN subnet. This is a good place to stop and test your current configuration. Plug a laptop in and see if you get a DHCP lease and test connectivity to both the pfSense interface and the CentOS DBAN server. If you’re not getting a lease and/or cannot contact both of those interfaces you will need to correct whatever is wrong with your network configuration before you proceed.
  • Modify your DHCP scope to “enable network booting”. Specify the IP address of the DBAN server, set the filename to ‘pxelinux.0’

4. DESTROY!

Plug a victim computer into your DBAN network choose boot from network. You should be presented with that glorious blue screen of impending doom.

 

Deploying VLC Media Player with SCCM

VLC Media Player is an F/OSS media player that supports a dizzying array of media formats. It’s a great example of one of those handy but infrequently used applications that are not included in our base image but generate help desk tickets when an user needs to view a live feed or listen to a meeting recording. Instead of just doing the Next-Next-Finish dance, lets package and deploy it out with SCCM. The 30 minutes to package, test and deploy VLC will pay us back in folds when our help desk no longer has to manually install the software. This reduces the time it takes to resolve these tickets and ensures that the application gets installed in a standardized way.

Start by grabbing the appropriate installer from VideoLAN’s website and copying to whatever location you use to store your source installers for SCCM. Then fire up the Administrative Console and create a New Application (Software Library – Applications – Create Application). We don’t get an .MSI installer so unfortunately we are actually going to have to do a bit of work, pick Manually specify the application information.

Next up, fill out all the relevant general information. There’s a tendency to skimp here but you might as well take the 10 seconds to provide some context and comments. You might save your team members or yourself some time in the future.

I generally make an effort to provide an icon for the Application Catalog and/or Software Center as well. Users may not know what “VLC Media Player” is but they may recognize the orange traffic cone. Again. It doesn’t take much up front work to prevent a few tickets.

Now you need to add a Deployment Type to your Application. Think of the Application as the metadata wrapped around your Deployment Types which are the actual installers. This lets you pull the logic for handling different types of clients, prerequisites and requirements away from other places like separate Collections for Windows 7 32-bit and 64-bit clients and just have one Application with two Deployment Types (a 32-bit installer and a 64-bit installer) that gets deployed to a more generic Collection. As previously mentioned, we don’t have an .MSI installer so we will have to manually specify the deployment installation/uninstallation strings along with the detection logic.

  • Installation: vlc-2.2.8-win32.exe /L=1033 /S –no-qt-privacy-ask –no-qt-updates-notif
  • Uninstallation: %ProgramFiles(x86)%\VideoLAN\VLC\uninstall.exe /S

If you review the VLC documentation you can see that /L switch specifies the language, /S switch specifies a silent install and the –no-qt-privacy-ask –no-qt-updates-notif sets the first-run settings so users don’t receive the prompt.

Without having a MSI’s handy ProductCode for setting up our Detection Logic we will have to rely on something a little more basic: Checking to see if the vlc.exe is present to tell the client whether or not the Application is actually installed. I also like to add a Version check as well so that older installs of VLC are not detected and are subsequently eligible for being upgraded.

  • Setting Type: File System
  • Type: File
  • Path: %ProgramFile(x86)%\VideoLAN\VLC
  • File or folder name: vlc.exe
  • Property: Version
  • Operator: Equals
  • Value: 2.2.8

Last but not least you need to set the User Experience settings. These are all pretty self explanatory. I do like to actually set the maximum run time and estimated installation time to something relevant for the application that way if the installer hangs it doesn’t just sit there for two hours before the agent kills it.

 

From there you should be able to test and deploy your new application! VLC Media Player is a great example of the kind of “optional” that you could just deploy as Available to your entire workstation fleet and close tickets requesting a media player with instructions on how to use the Software Center.

 

 

Until next time, stay frosty!