The Key to the Kingdom!

Hi everyone.  It’s been a few months since I last posted and I wanted to let everyone (who probably already knows about this wonderful tool) know about something I’ve just started using full-time.  If you aren’t familiar with it, there is a great “physical token” device out there called a “Yubikey.”  The purpose of this device is to use as a second factor (among other purposes) so that even if a bad actor manages to get their hands on your userid and password, they still can’t log into a device / site without also physically possessing the token.

There is similar technology where a text message with a one-time use code is sent to your mobile phone, but I’m not a fan of that given that someone could clone your SIM and have that text message directed at them instead of you.  This famously happened with Krebs on Security a few yearsa ago with his PayPal account.

The Yubikey is basically a USB device that you carry with you and you plug into your laptop’s USB type-A port when you want to log in.  There is a USB type C version (and apparently a two-headed beast that is USB-C and Lightning for iPhone users) but this one works best for me.  There is a little contact circle on it that lights up when the key is active and for some use cases, you touch that lighted circle for it to spit out the secret key associated with the device as if it were a USB keyboard attached to your laptop.  For multi-factor login, you don’t have to do this, you simply have to have a secret installed to the second “slot” on the key using the HMAC-SHA1 algorithm, not FIDO (which requires online access to a centralized server – not the use case I’m looking for).

The Yubikey I purchased is the Yubikey 5 NFC which also includes the ability to do NFC communication with cell phones.  I haven’t found a good use for that capability yet in my workflow, but I figured it was worth the extra few dollars to know that, if I do, I have the technology.

Setting up a Yubikey for multi-factor auth on Windows or Linux login isn’t exactly rocket science, but it is slightly challenging so I thought I’d document the process here.  There are other places you can use your Yubikey such as SSH logins, validating your GitHub connectivity, accessing your password vault in a variety of tools (Lastpass and Keepass), getting into your Facebook account and others.

For Windows 10 on my laptop, I run the “Pro” version.  There is software you can download from the Microsoft Store for Windows 10 Home / Windows Hello (if you have the IR camera capability on your laptop which I do not).  Unfortunately it seems to be not a multi-factor solution but a “skip the login screen if you have your key inserted” which I’m not a fan of.  I want true multi-factor auth in case someone steals my laptop and my Yubikey – I want them to have to know my password too.

Windows

To get the multi-factor auth software from Yubico that works in an offline mode with the HMAC-SHA1 secret on Windows 10 Pro, you do have to sign up for access to the early release code.  At the time I wrote this, it was not generally available yet.  However, before you install this software, you do need to configure the “slot 2” secret on your Yubikey.  To do this, install the Yubikey Personalization Tool from their website.  Run it with your Yubikey inserted into your laptop’s USB port.

Click on the “Challenge-Response” tab at the top and select the “HMAC-SHA1” button from the resulting screen.  Select the “Configuration Slot 2” radio button, click the “Generate” button and then press “Write Configuration” to save it.  You have the opportunity to save your key in a text file (which you can then print out if you wish to do so), but regardless, it will write the updated value to your device.  Once you have done this one time, there is no need to repeat the process so please don’t make the mistake of setting up Windows with the key and then replacing the secret in your device when you do Linux.  If you do so, you won’t be able to log into Windows again because you have wiped out the key’s secret when you reprogrammed it a second time.

OK.  Down to setting this up in Windows.  Before you do this, I strongly recommend that you create a local admin account so that if you mess things up, you can use it to log into your machine.  After you have done this (and just for the sake of sanity, reboot and verify that the account works and that you didn’t fat finger something – better safe than sorry), install the software that Yubico sent you a link to when you signed up for the beta.

You will be asked to reboot.  When you do so, your normal user account won’t work any more so you’ll have to log in as your local admin account you created above.  If you aren’t super familiar with Windows, you can use the .\username approach to log in as a different local user.  After logging in, you’ll need to run the Yubico Login Configurator application that you installed.  You will want to indicate slot 2 as your source for your HMAC and to use the existing secret you already programmed into the key.  Once you have selected this and moved to the next screen, you will be presented with a list of users to enable.  Choose your regular user, insert your Yubikey and press “Next” to complete the process.  At this point you should be able to reboot and log in as your regular user using your password and your Yubikey.  If you’d like, delete the admin account so that the only way you can log into your laptop is with your password and your Yubikey (if you are feeling bold / paranoid like me).

Linux

To do this on Linux (in my case, Ubuntu 19.04), you’ll first want to install the libpam-yubico and yubikey-manager packages.  On my particular version of Ubuntu, there was no need to add a third-party PPA as these packages were available in the default repositories.  Next, run the command “ykpamcfg -2” from your user account that you want to enable for two factor authentication.  Don’t use sudo for this, you’ll want it done as your regular user.  You should see that it created an initial challenge and expected response file in ~/.yubico/challenge-####### where ####### is the serial number that is unique to your key.

Now, to configure your system to require the Yubikey for login, you’ll want to add the following line to your /etc/pam.d/gdm-password file (your location might be different if you aren’t using GDM as your login manager like I am) right above the @include common-auth line:

auth    required    pam-yubico.so mode=challenge-response

If you make a mistake with this and manage to lock yourself out of your system, you can boot from a rescue CD, mount your filesystem, remove that line (or fix the typo in it like I had to) and then reboot (or you can create another user, add them to the “sudo” group and then delete the additional account when you are sure everything is working).  I run an encrypted filesystem so this ability to boot from a rescue CD doesn’t worry me as a back door, because an attacker would need to know the very complex password I have on my LUKS encryption.  Also, you can secure LUKS with the Yubikey as well (more on that later).  You should be able to reboot now and not log in unless you supply the correct password for your account along with having your Yubikey physically plugged into your machine.

If you’d like to require your Yubikey to use sudo on your account, then you can add that same line in /etc/pam.d/sudo in the same place.  It works great but I personally found it to be a bit much to have to use the Yubikey every time I run a sudo command versus just when I log in or unlock my screen when the screen saver kicks in.  It’s obviously up to you if you find the additional security to be worth the hassle.

If you’d really like to take things to the next level (and you run an LUKS encrypted filesystem like I do), then you can require your Yubikey to unlock your encrypted filesystem.  First, install the package yubikey-luks.  Then, edit the file at /usr/bin/yubikey-luks-enroll and modify the DISK variable to point to your encrypted volume.  After doing that, run the script as root.  You’ll be prompted for a new LUKS passphrase that will require your Yubikey (and you’ll have to provide your existing LUKS passphrase so that the change can be saved).  Once you’ve done that, you should be able to reboot and the LUKS volume will only unlock with that new passphrase if the Yubikey is installed.

Installing Snort on OpenBSD 6.4

As you may recall from previous posts, I am running an OpenBSD server on an APU2 air-cooled 3 Intel NIC box as my router/firewall for my secure home network.  Given that all of my Internet traffic flows through this box, I thought it would be a cool idea to run an Intrusion Detection System (IDS) on it.  Snort is the big hog of the open source world so I took a peek in the packages directory on one of the mirrors and lo and behold we have the latest & greatest version of Snort available!  Thanks devs!!!

I did some quick Googling and didn’t find much “modern” howto help out there so, after some trial and error, I have it up and running.  I thought I’d give back in a small way and share a quickie howto for other Googlers out there who are looking for guidance.  Here’s hoping that my title is good enough “SEO” to get you here!  🙂

As an IDS, the purpose of Snort is to examine all packets coming from the Internet to your network and from your network to the Internet.  The purpose of this inspection, unlike a firewall such as PF which is looking at ports and ensuring that you only expose the attack surface you mean to, is to use a set of know vulnerability (in the form of “snort rules”) to alert you if there is a problem.  The difference between an IDS and an IPS (intrusion prevention system) is that an IPS takes active steps to protect you, while an IPS like Snort just tells you “you have a problem.”

Installing snort from packages is pretty simple:

# pkg_add snort

After it’s done its thing, you now have a new /etc/rc.d/snort init script, a new _snort user and the snort files (along with dependencies) in the appropriate /usr/local directories.  The log files will show up in /var/snort/log and the configuration files are in /etc/snort.  The first thing I tried to do is run snort from the command line and discovered pretty quickly that it needs to know where its DAQ library (the functions that allow Snort to sniff traffic) is located.  To set this up, add the following line to your /etc/snort/snort.conf file:

config daq_dir: /usr/local/lib/daq

Now, we need to tell it which network represents our “internal” network and which represents the untrusted world of the Internet.  Near the top of the /etc/snort/snort.conf file, you will see the definition of “HOME_NET” and “EXTERNAL_NET”.  For HOME_NET you want to set it to use your local network.  For example, let’s say your local network was a class C network (255 possible IP addresses) at 10.0.5.x, you would use:

ipvar HOME_NET 10.0.5.1/24

You then want to define EXTERNAL_NET to be everything but that.  Fortunately, the syntax for this is pretty straightforward:

ipvar EXTERNAL_NET !$HOME_NET

At this point, you need to install your Snort rules.  There is a free “community” rule-set you can use that has all new rules delayed by 30 days, or you can crack open your moldy wallet, let a few moths out of it and spring $29.95 annually for the personal license for all of the latest & greatest rules.  Given that I like this tool and want to see it continue to be supported (and I want to be better protected), I’ll do the latter.  If you want to go the free route, I’ll leave it as an “exercise for the reader” to figure out how to make that happen.

When you subscribe, you get a userid and password that allow you to log into the https://snort.org website and download the latest ruleset.  Once you have pulled down the tarball (mine was called snortrules-snapshot-29120.tar.gz), scp it over to your OpenBSD router and unpack it in the /etc/snort directory.  Be careful – it will replace your snort.conf file so if you are dumb like me <grin>, you’ll have to re-apply your changes to it after you get confused as to why it isn’t working right.

At this point, you can either play around with Snort in the terminal or, if you are feeling particularly adventurous, make some changes to your rc.conf.local file via the beautiful rcctl tool that the wonderful OpenBSD devs created for us.  On my system, firing up Snort takes some time so I needed to set a timeout to a maximum of six minutes and I also have to pass it the interface I’m using (it defaults to your “first” interface but why take the chance):

# rcctl enable snort

# rcctl set snort flags -i em0

# rcctl set snort timeout 360

With that, a quick “doas reboot” and log back in will have you wondering if it worked.  Tail /var/log/messages until you actually see it spawn the daemon.  That will show you that it actually kicked things off.

At this point, Snort is monitoring your traffic and anything untoward will show up in /var/snort/log in either the “alert” logfile or the “snort.log.*” logfile.  You can find tools out there that will monitor your logs and notify you if something bad happens.  In addition, there is a tool that will keep your snort rules up to date as well that you can slap in a chron script if you’d like.

As I said, short and sweet, but I wanted folks who were interested in running this tool to at least have a good launching point on a more recent version of OpenBSD to hopefully leverage this great open source tool.

Well, it’s been a while – falling in love with OpenBSD again

I was checking the other day and was appalled at how long it has been since I posted here.  I had been working a job during 2018 that had me traveling 3,600 miles by air every week so that is at least a viable excuse.  🙂

So what is my latest project?  I wanted to get something better than the clunky old T500 “freedom laptop” that I could use as my daily driver.  Some background here.  My first paid gig as a programmer was on SunOS 4 (predecessor to Solaris) and Ultrix (on a DEC MicroVAX).  I went from there to a Commodore Amiga (preemptive multitasking in 1985!).  I went from there to OS/2 (I know, patron saint of lost causes) and then finally decided to “sell out” and move to Windows as the path of least resistance in the mid 90’s.

My wife bought me an iPod literally just as they started working with computers other than Macs and I watched with fascination as Apple made the big gamble and moved away from PowerPC chips to Intel.  That was the beginning of the Apple Fan Boi years for me.  My gateway drug was a G4 MacMini and I managed somehow to get in on the pre-production, developer build of an Intel-based Mac.  I was quite happy on the platform until about three years ago.

When the Mac laptop came out without an ESC key (it was on this gimmicky little one row display at the top of the keyboard that could be reconfigured based on your application), as a long-time VI user (the commands are programmed into my spinal cord, I really have no choice now) I was disgusted.  That forced me to recognize that I wasn’t Apple’s target market.  They wanted average computer users who didn’t care if they were on the latest and greatest chipset and they were getting more and more closed and “un-upgradeable” every day.

As much as I would have loved to be on OpenBSD for my daily driver, it seems that Skype for Business (or Lync or whatever they are calling it this week) is like a virus infiltrating the modern enterprise.  I ended up being quite happy on either Dell or Lenovo hardware running Ubuntu LTS on my work machine and Lenovo hardware running the latest & greatest version on my personal machine.  To satisfy my work need for Skype for Business, I ran a domain-joined VM of Windows 10 and felt like the dirty old days in the early 90’s on 16-bit OS/2 when you had to click on the “penalty box” and run a Windows program.

Well, the Ubuntu workflow has now gotten ingrained into me and as I was puttering around in my office, I came across my beloved Thinkpad x230.  I consider that to be the height of good, software-engineer oriented design and well balanced from a travel perspective.  Let me tell you what I mean.  The x220 was nice for the mechanical keyboard lovers (it was the last of the line to have that type of keyboard).  Although I’d love to be a “purist”, I have gotten so used to the chicklet keyboards, the one that they put in that x230 is pretty ideal.  Don’t get me started on the short-throw Apple keyboards – I can’t type my way out of a wet paper sack on those abominations.

Furthermore, unlike most modern laptops, the components on the x230 are all end-user upgradeable.  No RAM soldered to the motherboard, no whitelisted WLAN cards, the ability to have two hard drives, it was nice.  Although the CPU is a bit pokey compared to a “modern” one, it is no slouch and with 16 GB of RAM and a couple of 1TB SSD drives (one in the drive bay and an m2 SATA drive), it has more than enough gas in the tank.  Furthermore, with the 12″ screen and small form factor, it travels pretty darned well.  Also it was among the last to use the power connector that had graced Thinkpads for thousands of years (the round barrel one) which ensured that I had about 6.02 x 10^23 power adapters laying around somewhere in the house at any given time.

Seeing the old girl made me decide suddenly that I wanted to get a daily driver that was as secure (remember my Blog’s name!) and freedom-respecting as I could.  I read up on where things stood with Coreboot (now starting to hit more mainstream laptops) and was really impressed with how well the team had advanced the state of the art when it came to scary things like the Intel Management Engine.  Given that, it was time to get started.

I found a great blog post that had incredibly detailed instructions on what I needed to do in order to get a freedom-respecting, secure version of Coreboot built and installed on the x230 so I ordered a decent Pamona clip (don’t skimp on this – buy the brand name) and when it showed up, I spent about an hour and half building the image on my Ubuntu 18.10 Thinkpad T480 laptop (don’t ever buy the “S” models unless you hate upgrading things down the road) and flashing it onto the old girl.  When I was done, I had a great Coreboot, ME-cleaned, SeaBIOS machine that actually booted up first try!

With that behind me, it was time to wipe out the primary 1TB SSD and install OpenBSD.  I have been a continuous user of this incredible operating system (thanks Theo and the other devs!) for a long time now on my APU-2 firewall (see some of my earlier posts) and I ran it off and on over the years on various laptops.  The goal this time was different.  While this may disgust purists who want me to run FWM as my window manager and stick as close to base as possible, I had really gotten used to my Ubuntu workflow and wanted to see how much of that I could reproduce on this machine.

I started out by installing 6.4 on a full disk encrypted drive (the 1TB primary SSD in the laptop).  After the 4 minute “ordeal” (I love this OS) of doing that, I had a machine that would boot, but I needed to get some firmware to get things cranking.  I haven’t had a chance yet to purchase/replace my WiFi card to an Atheros, so I needed the Intel “iwn” firmware in order to ping out.  Once that was in place, it was time to focus on what I needed in order to have a machine that I could use as my daily driver, despite my “impairment” with the Ubuntu workflow. 🙂

First things first, I needed to do the necessary foo to get my user set up with doas support (I actually aliased doas to sudo on my Ubuntu machine, apparently that was something else I have programmed into my spinal cord – ha!), loaded VIM and aliased vi to it in my .kshrc and added colorls (which I alias ls to for some reason – habit on OpenBSD I guess).  With that, I installed the gnome shell to get a baseline going.  After a bit of a wait (it isn’t lightweight or standalone by any stretch of the imagination, but the fact that there are dedicated folks who keep fighting to make it work on OpenBSD despite the continuing downward spiral of systemd dependencies is a minor miracle).

With that in place, a quick reboot had me logged into a very bright-looking Gnome desktop environment.  I quickly put on sunglasses so that it didn’t blind me and started looking for a theme that would tone things down a bit for me.  I found a nice one called “Yaru-light” (Yaru is the new community theme for Gnome on Ubuntu 18.10) that gave me the right balance of contrast and darkness so that I could safely remove the sunglasses.  I added some OpenBSD wallpaper to the lock screen and the desktop as eye candy, used the Gnome Tweak Tool to get minimize and maximize buttons back and I started to feel more comfortable.

My personal email is on Office365 (don’t ask – it’s a long story involving the fact that I have a family member who loves Outlook on the Mac and it won’t open Google calendars) so I installed Evolution and Evolution EWS and got that working.  There is a bit of a bug when it comes to my folder list that I’m going to install the source to and see if I can fix and push upstream, but I have a workaround for it that I can live with for the time being.  After that, I threw on Libre Office and tweaked the UI to give me the infernal Microsoft ribbon UI that I’ve grown used to despite my best efforts to fight it off.

Printing was a bit of a bear until I realized I wasn’t connected to the same network as my infernal HP printer and then it suddenly got easy.  CUPS and a generic color Postscript driver to the rescue.  When that first page rolled off the printer (after fighting against my own stupidity – I mean come on, can you ping the printer dude?) I felt like the Tom Hanks character in “Cast Away” when he made fire for the first time on the beach!

I threw on “DashToDock” next so that I could get that nice sidebar that I never use.  For some reason I missed seeing it though so what the heck.  I had to install it manually because Firefox wouldn’t connect to the Gnome Extensions stuff correctly.  I later discovered that if I installed the chrome-gnome-shell package and the chromium browser (along with the Gnome extensions plugin for it), that I would easily install extensions from the browser in that.  Must have been a Firefox thing.

Next up was starting to lock stuff down from a security perspective.  I use Firefox as my default browser and am a big fan of the modifications recommended by privacytools.io – I wrote a little script that I keep updated with their latest changes so that I can apply it in a few seconds versus spending 10-15 minutes whacking around in the about:config page in the browser.  The only thing I haven’t figured out how to do is to modify the actual things that I tweak in the “settings” page (default search engine, etc.)

Now for the fun part.  Figuring out how to get my “NextCloud” files synchronized to this beast.  That has always been a challenge for me on OpenBSD.  There is no NextCloud desktop client but I have been told the old OwnCloud client should work – although I never could get it there.  I installed it, ran into the problem I had seen before (near immediate crash once it started downloading files to my local disk) and decided to exercise my Google fu.  Guess what, I found an old post of mine begging for help that some kind soul actually answered long after I had given up.  After some tweaks to /etc/login.conf and /etc/sysctl.conf I was off to the races.  Everything pulled down fine and I tested creating a new file in Linux and whammo – it showed up on the x230!

So in conclusion, I now have my primary workflow reproduced on OpenBSD with the exception of the infernal “Skype for Business” that always forced me into a Windows VM.  I’ve decided that my “new years resolution” (a bit late, don’t you think?) is to use that awful program on my mobile device and say to heck with it on my laptop.  Some remaining work that I need to do includes:

  • Buying an Atheros WLAN adapter off of eBay and installing it, thus eliminating one more piece of proprietary firmware that I have to use
  • Moving to -current with snapshots.  I just discovered that the packages there have Gnome 3.30 (bless you devs for continuing to fight the good fight here!) which may clear up my Evolution annoyance.  If not, time to download the source and see if I can fix it myself.
  • Start to do what I really want to do with OpenBSD – get all of the base Kali Linux pentesting tools into the ports/packages on OpenBSD and create a meta-package that installs them all.  Why should InfoSec professionals be forced to use an insecure operating system (Kali runs everything as root!) to do their jobs.  I’m guessing that this will be the content of a future blog post here.