Let’s dial it up to 11

So. It’s been a few months since I last posted here. I decided that the best way to sharpen my cyber skills would be to start treating my home environment like an enterprise one. In approaching this thought experiment, I thought:

“What key functions would I have in a production, enterprise network that I don’t have here?”

I have an IDS (Snort) but there are some holes:

  • Vulnerability scanning
  • Log aggregation
  • Centralized identity management
  • Endpoint protection
  • Etc.

In thinking through things, I decided I’ll tackle these one at a time. First things first, let’s get some log aggregation going.

After doing some research, I decided that the open source version of Graylog would be my choice for this function on my pseudo-production network. I thought about running this on my OpenBSD router/firewall, but decided that the stack necessary would just overwhelm the machine. Therefore I spun up a virtual host in my hosting environment of choice (DigitalOcean) and started installing / configuring things.

I decided to run Ubuntu 18.04 LTS for the core OS on the virtual machine and followed this tutorial to get Graylog up and running. Once I had the core server running, I decided to figure out how to get log data pushed to it. Since I want everything I do to be open source, I figured that rSyslog would be my best approach. It appeared to be native (or nearly native) on most of the operating systems I run and integrated nicely with Graylog.

I added a “Syslog UDP” Graylog input on a high numbered port on my server, used UFW to open a hole for the traffic and then started researching the arcane syntax of the /etc/rsyslog.conf file that would be necessary to work this bit of magic and get my log messages pushed to my aggregator. I figured it out in about 30 seconds but thought – “No way. It can’t be that easy!” and dug around for a while until I decided to just try it. Here is the incredibly complex piece of syntax you have to use:

*.* @your.graylog-server.example.com:1234

Where the single at sign means to use RDP, the 1234 is the port you are running the Graylog input listener on and “your.graylog-server.example.com” is the FQDN of your Graylog server. No kidding, it’s that easy!

Slug that in as the last line in /etc/rsyslog.conf on a Linux box, restart the rsyslog service:

sudo systemctl restart rsyslog

and you are cooking with gas. I’ve still not cracked the code with OpenBSD, but with all of my other ‘nix boxes, it’s dead simple. Now to tackle Windows (yes, I have a few Windows machines).

For Windows, the common wisdom on the Internet says you should use nxLog for the listener on the Windows box and you should ship the log data over to Graylog as a GELF format. After installing a GELF UDP input listener on Graylog and playing around for a while, I ended up with the following configuration file for nxLog that worked:

Panic Soft
#NoFreeOnExit TRUE

define ROOT     C:\Program Files (x86)\nxlog
define CERTDIR  %ROOT%\cert
define CONFDIR  %ROOT%\conf
define LOGDIR   %ROOT%\data
define LOGFILE  %LOGDIR%\nxlog.log

Moduledir %ROOT%\modules
CacheDir  %ROOT%\data
Pidfile   %ROOT%\data\nxlog.pid
SpoolDir  %ROOT%\data

<Extension _syslog>
    Module      xm_syslog

<Extension _charconv>
    Module      xm_charconv
    AutodetectCharsets iso8859-2, utf-8, utf-16, utf-32

<Extension _exec>
    Module      xm_exec

<Extension _fileop>
    Module      xm_fileop

    # Check the size of our log file hourly, rotate if larger than 5MB
        Every   1 hour
        Exec    if (file_exists('%LOGFILE%') and \
                   (file_size('%LOGFILE%') >= 5M)) \
                    file_cycle('%LOGFILE%', 8);

    # Rotate our log file every week on Sunday at midnight
        When    @weekly
        Exec    if file_exists('%LOGFILE%') file_cycle('%LOGFILE%', 8);

<Extension _gelf>
    Module      xm_gelf

<Input eventlog>
    Module  im_msvistalog

<Output out>
    Module      om_udp
    Host        your.graylog-server.example.com
    Port        1234
    OutputType  GELF

<Route 1>
    Path eventlog => out

Make sure to put in your FQDN for your Graylog server and the port number you are running your GELF input on.

At this point, I logged into each machine on my network and the log messages started flowing smoothly! Just for fun I set up an email alert capability and set some thresholds on failed root logins for the ‘nix boxes to let me know if anything funky is happening.

Next up – vulnerability scanning!

OpenBSD Full Disk Encryption with CoreBoot and Tianocore Payload

It has been a while since I have posted here so I wanted to share something that was surprisingly difficult for me to figure out.  I have a Thinkpad T440p that I have flashed with Coreboot 4.11 with some special patches that allow the newer machine to work.  When I got the laptop, the default BIOS was UEFI and I installed two operating systems.

  • Windows 10 with bitlocker full disk encryption on the “normal” drive (I replaced the spinning 2.5″ disk with an SSD)
  • Ubuntu 19.10 on the m.2 SATA drive that I installed using LUKS full disk encryption

I purchased one of those carriers for the optical bay that allows you to install a third SSD and so I did that with the intent of putting OpenBSD on it.  Since my other two operating systems were running full disk encryption, I wanted to do the same on OpenBSD.

Turns out that with a UEFI install, it is surprisingly hard.  My first attempts failed miserably.  Then, I had some inspiration.  I decided to install OpenBSD with no encryption and see if I could get things working with booting that from the Grub2 menu in Linux (where I also had an entry for Windows 10).  If I could do that, I figured I could go back and drop the non EFI partition and replace it with a softraid encrypted partition.

I installed OpenBSD “straight up” and was able to boot the disk from the boot menu in Tianocoare’s implementation of UEFI.  The trick was now to figure out what entry I had to make in Grub2 under Ubuntu to get things working.  I shot in the dark based on one web search after another and got no joy.  I decided to sleep on it.

When I attempted again, I remembered that you could hit the “c” key from the Grub2 boot menu and get an interactive Grub2 command prompt.  From here, I used the ls command to find the Grub2 name of my OpenBSD EFI partition that was created by the installer.  In my case, it turned out to be (hd2,gpt2).  I did an ls like this:

ls (hd2,gpt2)/

and was able to see the efi subdirectory (note the trailing slash!) and then could use ls to further explore and find the /efi/boot/ directory that contained the bootx64.efi bootloader file.

OK.  Now how can I get Grub2 to boot that.  Turns out there is a module you have to load called “part_msdos” (because the EFI partition is an msdos partition secretly).  I tried issuing the insmod part_msdos command (which was successful) and then used:

chainloader (hd2,gpt2)/efi/boot/bootx64.efi

Then I issued the “boot” command and I booted into my unencrypted OpenBSD partition.

Now that I had this, it was a simple matter to edit the 40_custom file in /etc/grub.d on the Ubuntu 19.10 system to create a special entry for OpenBSD:

menuentry “OpenBSD” (on /dev/sdc2) $menuentry_id_option ‘openbsd’ {
insmod part_msdos
chainloader (hd2,gpt2)/efi/boot/bootx64.efi

With that, I was able to boot from the Grub2 boot menu into my unencrypted OpenBSD partition!  w00t indeed!!

Now, to make it an encrypted partition.  I booted up from my USB install media for OpenBSD, dropped to a shell, and used fdisk in interactive mode to delete all of the non swap OpenBSD partitions from the disk – don’t delete the EFI partition!!!!!  After that, I created on single “a” partition and made it’s filesystem type “RAID”.  From there, I issued the bioctl command to turn that partition into a softraid encrypted partition:

bioctl -c C -l /dev/sd2a softraid0

I provided my password to decrypt the partition twice and voila, I had an sd4 encrypted disk.  I went back into the installer with the ‘exit’ command and installed OpenBSD as normal on the new sd4 encrypted partition that was visible.

Now for the acid test.  Without changing anything in Grub2, I rebooted and selected my “OpenBSD” menu entry.  Drumroll… Yep.  Everything worked!  I now have a Thinkpad T440p (hotrodded with a T450 touchpad, a 1080p IPS panel, 16 GB of RAM and an i7 4712MQ processor) running Coreboot instead of the stock BIOS with three SSDs, all encrypted with a nice menu to choose between OpenBSD 6.6, Ubuntu 19.10 and Windows 10 – all with full disk encryption!

By the way, if you are thinking about Corebooting a Thinkpad T440p, remember two things:

  1. You can’t use the stock 4.11 codebase, you need to add the special patches from “Archfan”.
  2. The OctoPerf site has a great breakdown of what you can upgrade with links to the magic necessary to get Windows 10 to allow you to install (and keep!) the driver for the Thinkpad T450 trackpad that replaces the horrific “clunkpad” that came with the T440p.

Happy Corebooting!