Functionally Paranoid

As return readers of this blog know, I try pretty hard to maximize my privacy and security online and also share what I’ve learned with the readers. One (in retrospect) painfully obvious hole, however, in my operational security (OpSec for the cool kids) is that I use the same bloody username for most of my online accounts. It doesn’t take a data brokerage genius to figure out that all of these accounts are owned by the same person. Duh!

So if you are a creature of habit like I am and would like to improve your operational security, I thought this would be a helpful post. I’m going to outline just how to do this along with some tools that are pretty useful as well. First off, what’s the best way to come up with a new username for a service that won’t give away who you are? Turns out, there are a variety of websites that will generate readable, random usernames for you. One that I found particularly helpful was from LastPass, a password vault application.

Thus armed, it’s now down to the laborious process of figuring out if you can rename your account on a variety of services and, if not, deleting and recreating said account by hand. You might also want to consider deleting some of these accounts if you don’t use them any more. That will reduce your personal attack surface in the event that one of these services is breached.

Just for fun, I have a set of links below that I discovered that should save you some time if you frequent these sites / services. What’s surprising is how many of these services do not let you rename your account. For those, it’s best to delete it unless there are specific digital purchased tied to that account (damn you Steam!).

• Discord
• eBay
• NoIP
• SiriusXM
• Twitter
• WordPress

After you think you are done, do yourself a favour and do a DuckDuckGo search of your commonly-used username. You might find some accounts out there that you had forgotten about. Chances are, if you forgot them you probably don’t use them so take the opportunity to delete them and decrease your attack surface further.

For those who aren’t as technically minded, it’s worth talking about what happens when you type a URL into your web browser and how that impacts privacy. The first thing is that the string you type in, say https://mycoolsite.com needs to be turned into a numeric IP address. This is done using a protocol called “Domain Name Service” or DNS that is as old as the hills. When you get an IP address from your Internet Service Provider (ISP), it’s usually done using something called Dynamic Host Configuration Protocol, or DHCP. At the same time you get that IP address, the ISPs DHCP server will generally pass other configuration parameters such as your DNS server.

OK, so that’s the mechanics of it. What is the privacy implication. Well, ISPs like to make money. And while they make money from you by providing you with Internet service, they also like to make money other ways. One of those is selling information on you to data brokers and advertisers. Since they are turning your URLs into IP addresses using their servers, it’s a pretty easy thing for them to sell the URLs that you like to visit to those data brokers and advertisers. Given that they have to log this information in order to sell it, they can also turn it over to government agencies when they are either subpoenaed or (worst case) handed a national security letter which they can’t even disclose that they were given.

In other words, your ISP knows every web site you visit and happily tells other people about it that you might not want told. Let that sink in for a moment. All of the work you might (or might not <sigh>) do to stay private online goes out the window when you type that address into your URL. By the way, this also goes for your mobile service provider. When you are out and about (i.e. not on WiFi), your cell service provider is your ISP and they have all of that same power and information. Yikes, eh?

So, what can you do about it? Well, using some other regular DNS provider like Google (with the famous 8.8.8.8 DNS server) or CloudFlare doesn’t really help because who trusts their motives? You could use a privacy-respecting DNS provider that doesn’t log their information and has a warrant canary (a mechanism where they regularly post on their website that they haven’t been issued a national security letter until they stop posting that – which means they have), but since the DNS protocol is as old as the hills, that traffic is sent unencrypted over the internet and an adversary could capture it anyhow.

What to do? Well, there is a clever multi-part solution that I’m going to outline here for Linux, OpenBSD (of course) and Windows. It involves running a local DNS resolver on your laptop or desktop machine (why let your ISP resolve them when you can do so yourself) and when your local resolver doesn’t know the answer, using a protocol called DNScrypt to send that DNS request in an encrypted fashion, upstream to a DNS server that doesn’t log and is privacy respecting. It’s not airtight (that upstream server could be lying about being privacy respecting or could get compromised and not even know it) but like most privacy and security, the goal isn’t to be perfect, it’s to make yourself a much harder target so that the bad guys look for easier sheep to fleece.

Linux

For my example in Linux, I’ll be using Ubuntu 20.10 as the target operating system and version so if you are on a different distribution, your mileage may vary but the building blocks will be the same. I based this how-to on a combination of a Reddit post that I found while searching DuckDuckGo (you REALLY should stop using Google and who uses Bing anyhow?), a great article on LinuxConfig that I found the same way and finally

First things first, you need to install the necessary open source tools:

# apt install dnscrypt-proxy dnsmasq

Next, add the line “dns=127.0.0.1” to the [main] section in your local /etc/NetworkManager/NetworkManager.conf file. This tells NetworkManager to force the DNS manager to be the one installed locally (hence the “localhost” bit) on your machine.

After that is out of the way (please don’t reboot now because you won’t have the necessary other bits configured, please be patient <grin>), edit your local /etc/dnscrypt-proxy/dnscrypt-proxy.toml configuration file to set up the upstream server you want to use. I’d recommend taking a look at this list because 1) it’s from the documentation site for DNScrypt; and 2) it has a list of servers that are privacy respecting and don’t log connections. I’d also recommend refreshing your memory as to who the “Fourteen Eyes” nations are who do intelligence sharing with the US and try to pick a resolver that is in a country not on that list. Just sayin’…

Anyhow, add the following lines in the global section of the file:

listen_addresses = [‘127.0.0.1:53000′,'[::1]:53000’]
server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

I chose to use multiple servers in my configuration to make it resilient in case one of them happens to fail. I’m making the assumption (check my math on this) that the first two (the ones in Switzerland – my privacy-respecting country of choice) are the primary and the other one is there as a back-up in case the first two don’t respond.

Because I couldn’t get the “listen_addresses” bit working from the config file (I left it in there just in case), I also edited the /etc/systemd/system/sockets.target.wants/dnscrypt-proxy.socket file to specify the port I want this service running on. In the [Socket] section, I modified the two lines with the port 53000 setting that I have in the config file:

ListenStream=127.0.2.1:53000
ListenDatagram=127.0.2.1:53000

Now that we have DNScrypt set up, we need to set up the dnsmasq service to be our local, lightweight caching resolver that forwards its upstream resolution requests to DNScrypt. To do this, we need to edit it’s configuration file /etc/dnsmasq.conf and add the following lines (the default file has everything commented out so instead of searching for them and un-commenting them, I just slammed this at the end of the file):

no-resolv
server=::1#53000
server=127.0.0.1#53000
listen-address=::1,127.0.0.1

After setting this up, there is a REALLY IMPORTANT STEP you need to do and that is to disable systemd-resolvd:

# sudo systemctl disable systemd-resolved

After you have done this, you should be able to reboot and resolve DNS names (easy test, go to a site you rarely visit in your browser). To verify that it is your privacy-respecting configuration that is doing this, try the following tests:

# sudo lsof -iTCP:53000 -sTCP:LISTEN

You should see several lines showing tha t the proxess “dnscrypt” running as user “_dnscrypt-proxy” is listening on this socket.

Next, check who is listening on port 53 (the “regular” DNS port):

# sudo lsof -iTCP:53 -STCP:LISTEN

You should see that the process ‘dnsmasq’ running as user ‘dnsmasq’ is listening on this socket. So far so good.

Now, use the ‘dig’ command to force the resolution of a URL that you don’t normally visit:

# dig -t A microsoft.com @127.0.0.1

You should get a display of the IPs that match that URL. Finally, if you are really paranoid (and I am), verify that by turning off dnscrypt-proxy that you CANNOT resolve DNS queries:

# systemctl stop dnscrypt-proxy
# systemctl stop dnscrypt-proxy.socket
# dig -t A oracle.com @127.0.0.1
# dig -t A oracle.com

This should fail to resolve things. Make sure you restart the two systemd services after you have verified this.

Congratulations. You have just significantly improved the privacy of your machine. Now go do this on all of your Linux systems.

OpenBSD

I listed these sections in alphabetical order so don’t read into my choice of having “Linux” first as an indication that I don’t love me some OpenBSD! For this part, I used my coreboot+tianocore Thinkpad T440p running OpenBSD 6.8 off of a secondary drive (the primary drive had the fresh Windows 10 install on it for the Windows version of this how-to).

First things first, we need to install dnscrypt-proxy:

# pkg_add dnscrypt-proxy

The configuration file is logically /etc/dnscrypt-proxy.toml and you need to edit it and add our server_names and listen_addresses to it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]
listen_addresses = [‘127.0.0.1:53000′,'[::1]:53000’]

Once you have that saved, you should enable the daemon using the following command:

# rcctl enable dnscrypt_proxy

Note the underscore instead of a dash there for the daemon name. Now start it up:

# rcctl start dnscrypt_proxy

To verify that the daemon is running and listening on our desired port, simply use netstat:

# netstat -an | grep LISTEN

You should see that there is a process listening on port 53000 in both localhost IPv4 and IPv6.

Now we need to get a local resolver running and forwarding to DNScrypt. Fortunately, OpenBSD has a really nice builtin one called unbound. Enable and start it using the following commands:

# rcctl enable unbound
# rcctl start unbound

Now we need to tweak our dhcp configuration (if you are not running a static IP address) to override any “suggested” name server from your dhcp server. To do that, edit the /etc/dhclient.conf file and add the line:

supersede domain-name-servers 127.0.0.1;

Restart your network with the following command:

# sh /etc/netstart

And then check your /etc/resolv.conf file to verify that the name server is in there along with no other.

Use the following commands to verify that your DNS resolution is working using unbound locally:

# dig -t A microsoft.com @127.0.0.1
# dig -t A microsoft.com

Assuming that goes well, now we need to edit unbound’s configuration file to use localhost port 53000 for our upstream resolver. That file is in /var/unbound/etc/unbound.conf and you need to edit the forward-zone section to look like this:

forward-zone:
name “.”
forward-addr: 127.0.0.1@53000

In addition, in the “server:” section of the file, you need to add the following line in order to get the forwarding working properly between the unbound daemon and the dnscrypt-proxy daemon. Without it, localhost will be ignored for queries:

do-not-query-localhost: no

Use the following commands to restart the service and validate that name resolution is working:

# rcctl restart unbound
# dig -t A oracle.com @127.0.0.1
# dig -t A oracle.com

Now, to verify that you have unbound listening on port 53 and dnscrypt-proxy listening on port 53000, run the following:

# netstat -an | grep LISTEN

If you see listening processes on both the IPv4 and IPv6 ports, you should be good. Finally, to verify that the upstream requests are being forwarded to dnscrypt-proxy, stop its daemon and test using dig:

# rcctl stop dnscrypt_proxy

Windows

OK. Whew. I’m going to be a bit out of my depth on this one (I’m not a big-time Windows power user any more) but the Internet has some good stuff on it so here goes nothing. For my setup, I had a dead-fresh install of Windows 10 on my coreboot + tianocore Thinkpad T440p that I’m using. I figured that way no extra configuration would get in there that might mess things up.

I figured there are a lot of bad actors on the Internet who might post some bad info on how to set this up in such as way as to route all of your traffic to them (forgive me, I’m paranoid <grin>), so I thought the best place to go would be the GitHub repository for the DNScrypt-proxy project.

From there, I clicked the link to download the latest version of DNScrypt-proxy for Windows. Given that, I read the documentation on how to install the service myself, not using a possibly compromised “helper”. Also, this helps me learn where the files are and how to configure things which is always good. I’ll document my process here. From this point forward, assume that I’m running a PowerShell command prompt with the “run as Administrator” option.

I copied the contents of the “win64” directory to C:\Program Files\DNScrypt-proxy to start things off. Best to have it in a “standard” (I think) place. I then move to that as my current directory. Next, copy the example-dnscrypt-proxy.toml file to “dnscrypt-proxy.toml”:

PS > copy example-dnscrypt-proxy.toml dnscrypt-proxy.toml

Edit the file using notepad (I guess) to have the same server_names line that we had for the Linux install above:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Now, let’s make sure everything is working by running ./dnscrypt-proxy from that PowerShell prompt:

PS > ./dnscrypt-proxy

You should see some diagnostic information finishing up with “dnscrypt-proxy is ready – live servers: 2” in your PowerShell prompt.

The instructions are a little off on the version of the page I was looking at (or maybe my Windows 10 fu is weak). Anyhow, I went old-school and went to my “Wi-Fi” settings in the UI and selected “Change adapter options” from the link on the right. I then went to my “Ethernet” and “Wi-Fi” icons, right clicked on them, selected “Properties” and then went to the “Internet Protocol Version 4 (TCP/IPv4)” item and clicked the “Properties” button.

For both adapters (Ethernet and Wi-Fi), I changed the page to “Use the following DNS server addresses” radio button and entered 127.0.0.1 in the “Prefered DNS server” address and “9.9.9.9” as the “Alternate DNS server” per the instructions. Just for shits and giggles I checked the “Validate settings upon exit” checkbox and hit OK. I didn’t get any error messages so I’m assuming it’s good.

I then repeated the process with the IPv6 properties, setting the “Preferred DNS Server” to “::1” (without the quotes) – the equivalent of localhost in IPv6 land. I also set the “Alternate DNS server” to “0:0:0:0:0:ffff:909:909” which is the IPv6 address of that server.

Back to the PowerShell prompt, I hit “Ctrl+C” to break out of the dnscrypt-proxy process that was running and executed the following command:

PS > ./dnscrypt-proxy -resolve example.com

This successfully verified that I was able to resolve the DNS query using my configuration file. Now for the fun part, installing the service. To do this, run the following command:

PS > ./dnscrypt-proxy -service install

If you don’t get any error messages, start the service:

PS > ./dnscrypt-proxy -service start

Assuming you are error free there, you actually have a working (without a local caching resolver) install of DNScrypt-proxy. The final step is to fiddle with a Windows 10 group policy setting for the Network Connect Status Indicator (NCSI) to prevent it from showing your network as “offline”.

To do this, run “gpedit.msc” to launch the Group Policy Editor. From there, drill down to:

Computer Configuration -> Administrative Templates -> Network .> Network Connectivity Status Indicator

In the right-hand pane, select the “Specify global DNS” policy and click the “Enabled” radio button. Now check the “Use global DNS” checkbox and hit OK.

At this point you should be safe to reboot and verify that things are working. After the reboot, bring up a “run as Administrator” PowerShell prompt and run the following command:

PS > netstat -a -b

You should see dnscrypt-proxy.exe listening on port 53 of the localhost IP address. Bring up a browser and hit a site you rarely visit to verify that you have name resolution working.

I don’t have the local cache part of this working on Windows yet but all I’m losing there is efficiency because I’m doing the DNS lookup each time I need to resolve something. All said, I think I improved the privacy of my Windows 10 install by a non-zero amount! 🙂

Mobile?

So what about mobile? That tends to be a platform that we all spend a lot of time on these days and I’d hate to leave it out. While my experience and expertise doesn’t allow me to truly test that this works like I can on desktop operating systems where I can use tcpdump, turn services on or off, etc. some sites that I trust lay down some recommendations that appear to be working when I test them. Therefore, use this at your own risk and do testing that you think makes sense for you and your threat model.

For iOS, I found the following link from PrivacyTools.IO (one of my favorite sites) that walks you through how to use an app on the iPhone to run dnscrypt-proxy as your local DNS resolver on iOS. Essentially, you need to install the app, click on the “edit” button in the toolbar when you launch it and add our standard “server_names” line below, then hit the checkmark button in the toolbar to save it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Then, you will want to click on the “hamburger button” in the toolbar on the left and turn on the “Connect On Demand” general option. After that I rebooted my phone just for good measure and I appear to be up and running.

For Android, I found an application on the Google Play store called Quad9Connect. It appears to use secure DNS to access servers but it lacks the fine-grained control I would like in order to specify which countries I want those DNS queries to be tunnelled through.

Another Android app that I have seen recommended on a variety of sites is InviZible Pro. This app allows you to have more control over your DNScrypt-proxy setup. The settings I’m running with are to turn off the Tor support, leave the DNSCrypt support on and set it to run at boot-time. I also turn on the “require_nolog” feature in the DNSCrypt Settings page. Finally, I go into the Network & Internet settings in Android, selecct VPN, select settings for InviZible Pro and enable “Always-on VPN”.

In looking back over my most recent posts on this blog, I’m noticing a pattern. I’m tending to focus on technical aspects of privacy and security and am leaning more towards the security side of things. Given that I want to be balanced in the information I share here at FunctionallyParanoid, I thought it would be a good time to start making a concerted effort to share some information that isn’t focused on installing operating systems or configuring software. In this post, I’m going to talk to you about the evil role of “data brokers” in the world today and what you can do to limit their nefarious impact on your life.

Data brokers are not a new invention of our modern computer age. They have been around for thousands of years. As long as a given piece of information had value to someone else, they work to maximize that value and monetize it to their benefit. For example, if you knew the location of an invading army, you could sell that location to the country being invaded, regardless of whether it was the twenty-first century or the first century. For that matter, you could then turn around and sell the fact that the element of surprise was lost to the invading army and suggest they take a different route for their invasion and so on. Nice work if you can get it, eh?

The modern data brokers also set themselves up to sell the same information multiple times. What they do is comb through tons of data – things like mailing lists for catalogues, marketing databases, etc. They then correlate that information and assemble a dossier on each person that they can tease out. Once they assemble that dossier, they can then sell it to firms that want to market to you, to people trying to track you down to collect on a debt, whatever. The information is for sale to the highest bidder.

Yes, there are some limitations to what they can do, but it really depends on where you live. For example, if you live in California, there is a new data privacy law that places some realistic limits on these firms; however, if you live in Montana, you are pretty much on your own. There really isn’t a lot of privacy protection at the federal level.

Given that, what can you do? Well, for one, you can work to either correct or delete the information that these data brokers have on you. While there are services you can pay to do this on your behalf, I thought I’d do this the old fashioned way and see how good a job I can do using a little elbow grease and trying my hand at getting my information deleted.

The first thing you need to do is get a list of who the data brokers are. That is surprisingly difficult to do in a canonical way. However, after a series of DuckDuckGo searches (of course I use them and not Google – I’m FunctionallyParanoid after all), I was able to come up with the following list. What I’ll do is keep this post in draft form as I go through the process of requesting that my information be deleted and add tips and additional information on each broker as I knock them out.

As a sidebar, there is a service called Blur that allows you to get a free email forwarder that masks your email address. Essentially you put in your “blur” email address and then the email actually comes to you but the sender doesn’t really know what your true email address is. Might not be a bad idea to use a service like this for the removal emails where they require confirmation. Just a thought.

Here we go…

Acxiom

This is one of the big ones. You need to navigate to their opt out page and wade through a plethora of text about why this is a bad idea and you really should love having your data sold all over the place without you knowing who gets it. You then have to fill out a form at the bottom of that screen where the difference between the text and the white background is about +1 on the RGB scale – in other words, it is nearly indecipherable. After you squint your way through that, you will get an email that requires you to click a link to ensure that the information is deleted. As with all of these, set a calendar reminder to check back and ensure that your information has truly been removed.

BeenVerified

This broker seems to be the easiest to deal with and pretty quick in terms of deleting the information. Go to their opt out page and search for your information. Once you find your record or records (I found old addresses listing me with different middle initials), click on each one, supply an email address (yes, you have to do this because they require you to click a link in the email they send you to actually kick off the removal process), help Google or whoever identify busses or fire hydrants, and then wait for that email to show up. Once you click the link, they will begin the process and have you removed in 24-48 hours. Put a calendar reminder out there to check that you have been removed and see if there are any other records that need to be deleted.

Epsilon

Another big one. These folks have not only the ability to sell your data for offline purposes, they can do it online. And, they purport to be able to connect the two. Yikes! To get your data removed, go to their opt out page and fill it out. Just like with Axciom above, you have to wade through some text to get to the form. Again, don’t forget to set a calendar reminder to check back and ensure that the data has been deleted.

Intelius

This one is probably the easiest of the bunch. You simply navigate to their opt out page, search for yourself and then request that they delete the information. As with all of these, put a calendar reminder in your calendar to ensure that the information has been deleted.

MyLife

This one is a pain. You have to “join” their service (which to me seems to indicate that they have more accurate information on you) but you can obfuscate that information. Anyhow, once you join you can then search for your information and send an email to privacy@mylife.com to have them remove you. Include the URL from your search in the email and don’t forget to put a calendar reminder in to verify that it has been deleted.

Raradis

Similar to the others, you first have to search for your record on their site. You then copy the URL from your browser’s address bar and paste it into the opt out form to have them remove your information. They will notify you when the information is removed. When they did, I actually checked and my information was NOT removed. An email to customer service corrected the issue and my information was removed.

Spokeo

This one is pretty similar to many of the others. Go to their search page and look for yourself. Once you find a record you wish to remove, click on it, save the URL from your browser’s address bar and supply it to their opt out page. As with all of these, you’ll have some email interaction with them and they will let you know you have started the process. I strongly recommend taking their timeframe for removal and putting a reminder in your calendar to check up on it and make sure the information is truly gone.

WhitePages

This one is more pernicious. They seem to have lots of different records of me that need to be deleted. The process is pretty straightforward, however. You go to their search page and look for your information. After you find your listing, if you are fortunate enough to see one with an arrow at the right, click on that and copy the resulting URL from the address bar. You can then go to their opt out page, provide the URL and go through the request process. Since this broker sources from public records, I can’t find a way to delete their “premium search” and they still list your personal information (such as home address) on their search pages. To get around this, I tried using their CCPA opt out form because my records can be found by searching an address in California.

Conclusion

To net this out, it’s a few minutes worth of work but the end result is that your data isn’t being monetized by some faceless corporation somewhere. If you then have good hygeine on your privacy, perhaps you can reduce your data footprint to keep from being an interesting target for these brokers. Either way, it is probably worth checking in on your status on these sites a couple of times a year or more.

I probably should have checked the mailing lists before writing my last two blog posts on how I install and “beautify” an OpenBSD bare-metal install on a laptop because sure as I was done with the second one and shared it to my friends on Reddit, I saw the announcement that 6.8 was available. Well, probably a good time to show how I do an in-place upgrade of a running system. I heavily leverage this post from the main site, so I thought I should give it a shout out for its helpfulness!

First things first, I make sure I have patched up to the latest and greatest kernel of what I’ll now be calling the “old version” of OpenBSD:

# syspatch

I then make sure my firmware is fully upgraded:

# fw_update

Then, just for double-dog-sure’edness (I just made that compound word up on the spot), I reboot:

# reboot

By the way, I always have my laptop set to boot into Windows by default so that if it is “checked” at a border crossing (I always approach security with all of my devices powered down) it boots into a benign and mostly unused install of Windows. I know, it’s a bit “security through obscurity” but what the heck, right?

If this is the first upgrade for the system, I create a directory called /root/upgrade and then within it create subdirectories for the versions where I copy the files. I generally clean out the old one when I’m setting up a new one just to preserve a little disk space:

# mkdir /root/upgrade
# cd /root/upgrade
# mkdir 6.8
# cd 6.8

I now download all of the install files from the CDN using the built-in ftp client (I used to use wget but why install another port if you don’t need it <grin>):

# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/base68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/comp68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/game68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/man68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/xbase68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/xfont68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/xserv68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/xshare68.tgz
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/bsd
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/bsd.mp
# ftp https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/bsd.rd

For those who are extra paranoid like me, I always make sure I have a total of 11 files in this directory. Remember the name of the blog after all… <grin>

Now, you are about TO DO SOMETHING DANGEROUS to your system so don’t blame me if it goes awry. The sequence is very critical because you need to preserve an “old kernel” reboot command and only update the “base” install last. Otherwise you will get in a situation where you have the wrong userland files for the kernel you are running and things will get messy. So, here goes everything in the correct sequence:

# ln -f bsd obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
# cp bsd.rd /
# cp bsd /bsd.sp
# sha256 -h /var/db/kernel.SHA256 /bsd
# cp /sbin/reboot /sbin/oreboot
# tar -C / -zxphf xshare68.tgz
# tar -C / -zxphf xserv68.tgz
# tar -C / -zxphf xfont68.tgz
# tar -C / -zxphf xbase68.tgz
# tar -C / -zxphf man68.tgz
# tar -C / -zxphf game68.tgz
# tar -C / -zxphf comp68.tgz
# tar -C / -zxphf base68.tgz

I then comment out all of my cool stuff in /etc/rc.conf.local and reboot using the old reboot command:

# /sbin/oreboot

You then need to update some other things as root:

# cd /dev
# ./MAKEDEV all
# installboot sd1
# sysmerge
# fw_update

I typically reboot (just to be safe) and then log in as root and update my packages:

# pkg_add -u

Finally, remove the old reboot command:

# rm /sbin/oreboot

Uncomment all of the cool stuff in your /etc/rc.conf.local and reboot. At this point you should be AOK and running the new kernel, userland and packages from the release version!

If you get stuck somewhere along the way, remember you can boot into single-user mode with:

boot> boot -s

You can then manually mount your filesystem and poke around to see what you need to fix. This should serve to reinforce why having physical possession of a machine trumps most of your security preparations and also reinforce the need to run a full-disk encryption (if you aren’t already).

I hope you found this post helpful!

In my last blog post, I shared how I set up my OpenBSD laptop from the bare metal. In retrospect, there are a handful of UI tweaks that I also perform to make my UI and workflow more consistent between my OpenBSD machines and my Linux (Ubuntu) machine. I know that the purists out there are crying “boo hiss” but then they probably were crying that when I talked about using Gnome instead of cwm and xenodm for my window manager <grin>. Here are some things that I like to do.

First things first, I had forgotten that I prefer to use the “regular” (not dark, not light) version of the Yaru-remix theme from https://gnome-look.org because it keeps the menu bar and window titlebars dark while still leaving things like Evolution’s list of folders, preview pane and list of messages pane with a light background. Again, more like what I see on Ubuntu in my Linux machines.

For my terminal prompt, I had forgotten at the time I did the nuke and re-pave that I had moved away from the old “green screen” look (green on a black background) and went with white on a black background to get the base look set up. I then use the ability to inject color into the PS1 prompt so that the machine name shows up in green and the current working directory shows up in blue with a white dollar-sign prompt by making this change in my ~/.profile file:

export PS1=”\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$ “

Next, I need to install the colorls package using “pkg_add” and enable a .kshrc file by adding this line to my ~/.profile file:

export ENV=$HOME/.kshrc

In the ~/.kshrc file itself, I add an alias to make a regular issuance of “ls” actually fire the colorls command:

alias ls=”colorls -G”

and just for giggles, I use “pkg_add” to import the vim (non-x11) package and make my old timey SunOS4 muscle memory not betray me when I’m trying to edit a file and mistype “vim” as just straight-up “vi”:

alias vi=”vim”

I also add this line to my /etc/rc.conf.local file (I haven’t figured out the magic syntax for rcctl to do this with no flags):

ntpd_flags=””

and then start the NTP daemon:

# rcctl start ntpd

Since I maintain several ports on OpenBSD (yeah, I know, I need to update some of them – I’m working on it! <grin>), I like to set up anonymous CVS access to the ports tree by adding this to my .profile:

export CVSROOT=anoncvs@anoncvs1.ca.openbsd.org:/cvs

and then do an initial checkout of that and the rest of the OpenBSD source code for good measure by running:

# cd /usr
# cvs -qd anoncvs@anoncvs1.ca.openbsd.org:/cvs checkout -rOPENBSD_6_7 -P src ports xenocara

I also make Firefox my default web browser and follow the recommendations at https://privacytools.io to ensure that I have it configured to maximum privacy mode.

One thing I’ve noticed is that it takes Gnome Evolution 3-4 launches to correctly pick up folder names in my EWS and IMAP mail services. I’m not sure why that is (it seems like some sort of network timeout more than anything else) but it’s just a minor annoyance. Keep re-launching it after it settles down and eventually it will get it right.

The other Evolution annoyance is that it doesn’t correctly identify the SPAM, TRASH and INBOX folders so some of the nice shortcuts you get from the context menu to expunge things (for example) and some of the nice automatic sorting of “Inbox” to the top of the folders list doesn’t happen with EWS accounts. Again, annoying, but it doesn’t limit the basic functionality of the email client.

Since it takes several hours (days?) to sync all of my NextCloud documents and email archive data, I generally try to switch off suspend when plugged in until everything is synced the first time. After that, I go back to a suspend after an hour of inactivity mode for my normal use. While you are in the settings app changing that, it’s a good time to turn off the notifications on both the main screen as well as the lock screen if you find them as annoying as I do.

In conclusion, these little tweaks and configuration allow me to have a pretty consistent workflow across all of my laptops/workstations so that I can continue the programming of my spinal cord that has been ongoing since the 80’s when it comes to working on *nix systems. I hope you found this to be a useful read.

Hi, I know it’s been a while. I recently had to nuke and re-pave my personal laptop and I thought it would be a nice thing to share with the community how I set up OpenBSD on it so that I have a useful, modern, secure environment for getting work done. I’m not going to say I’m the expert on this or that this is the BEST way to set up OpenBSD, but I thought it would be worthwhile for folks doing Google searches to at least get my opinion on this. So, given that, let’s go…

After downloading the install67.fs image from my favorite site (https://openbsd.cs.toronto.edu/pub/OpenBSD/6.7/amd64) I write it to a USB drive on Linux with:

$ sudo dd if=install67.fs of=/dev/sdc bs=1M

I then boot off of that USB drive and drop to a (s)hell at the install prompt. From there, I create the full disk encryption container for my install:

# cd /dev
# chmod +x ./MAKEDEV
# ./MAKEDEV sd1
# fdisk -iy sd1
# disklabel -E sd1

Create one big “a” partition for the whole drive but specify RAID as the partition type.

# bioctl -c C -l /dev/sd1a softraid0

I then enter my decryption password and type ‘exit’ to restart the installation. The only tweak I make to the installer is to set up my wifi (it won’t work in the installer or on reboot for me because I have an Intel ‘iwm’ device that needs the firmware installed – I do that later) and make sure that my /usr partition is at least 200g in size (I probably should but I don’t create the subdirectory mount points, just one big /usr).

After the first reboot, I go back to my Linux box with the same USB drive, turn it into a single partition FAT32 drive and download the firmware for my Intel ‘iwm’ device from https://firmware.openbsd.org/firmware/6.7 as a single .tgz file that I place on that USB drive. I then mount the drive on OpenBSD:

# mount /dev/sd2i /mnt

Next, I copy the .tgz file to the /etc directory and expand it there. It will automatically put the right files in the /etc/firmware directory. I then reboot and should have WiFi. I then update the other firmware:

# fw_update

Next, I run syspatch to ensure that I’m fully patched on the kernel and userland I’m running:

# syspatch

That takes a bit of time, just be patient. At this point, it’s best to reboot because so much has changed on the disk from what is running in memory. You should see in the dmesg output that all of your firmware installed successfully and that the kernel relinked to help fight off potential ROP attackers.

First things first, I create an /etc/doas.conf file so that I can run everything in my regular user account:

# echo “permit persist keepenv MY_USERNAME as root” > /etc/doas.conf

Next, I set up power management (because I’m running on a laptop):

# rcctl enable apmd
# rccl set apmd flags -A
# rcctl start apmd

Since I run development tools and the owncloud desktop, I have to tweak some values in /etc/login.conf to make things work the way I want them to. First, I add myself to the “staff” group:

# usermod -G staff MY_USERNAME

I then edit /etc/login.conf in the “staff” section to make the following changes:

# pkg_add vim
# vim /etc/login.conf

…
staff:\
:datasize-cur=4096M:\
:datasize-max=infinity:\
:maxproc-max=512:\
:maxproc-cur=256:\
:openfiles-max=102400:\
:openfiles-cur=102400

I also modify /etc/sysctl.conf to include the line:

kern.maxfiles=102400

I then will typically reboot to pick up the changes.

Next, I want to install the Gnome desktop environment and the Gnome display manager. It’s what I’m most comfortable in and I know it’s a pain in the you know what for the port maintainers to keep it working on OpenBSD because of the Linux-ism’s that keep creeping in so I want to put in a shout out to them for all of their hard work on this.

# pkg_add gnome gnome-tweaks gnome-extras
# rcctl disable xenodm
# rcctl enable multicast messagebus avahi_daemon gdm

Install my favorite applications and utilities:

# pkg_add firefox chromium libreoffice owncloudclient
# pkg_add keepassxc aisleriot evolution evolution-ews
# pkg_add tor-browser shotwell gimp

I will reboot at this point and go into Gnome with the default theme. That needs fixing so I download the yaru-remix-complete theme from https://www.gnome-look.org and install it manually by doing the following:

$ cd ~
$ mkdir .themes
$ cd .themes
$ mv ~/Downloads/Yaru-remix-complete.tar.xz .
$ unxz Yaru-remix-complete.tar.xz
$ tar xf Yaru-remix-complete.tar
$ mv themes/* .
$ rmdir themes
$ doas mv icons/* /usr/local/share/icons
$ rmdir icons
$ doas mv wallpaper/* /usr/local/share/backgrounds/gnome
$ rmdir wallpaper
$ rm Yaru-remix-complete.tar

Fire up gnome-tweaks and from “Extensions” turn on “user-themes”. Close and restart gnome-tweaks, go to the “Appearance” tab and select “Yaru-remix-dark” for “Applications”, “Icons” and “Shell”. ON “Top Bar”, turn on “Battery Percentage” and “Weekday”. In “Window Titlebars” enable “Maximize” and “Minimize”.

Enable the extension “Dash to Dock” by downloading it from https://extensions.gnome.org/extension/307/dash-to-dock/ and pick the right shell version and extension version to match your install of Gnome shell. You will have to manually install it because the Gnome shell extension integration doesn’t appear to be enabled for OpenBSD:

$ cd ~/Downloads
$ unzip dash-to-docmicxgx.gmail.com.v67.shell-extension.zip
$ cat metadata.json

The value for “uuid” is what you want to use next:

$ mkdir -p ~/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com
$ cd ~/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com
$ unzip ~/Downloads/dash-to-docmicxgx.gmail.com.v67.shell-extension.zip

Reboot to restart Gnome shell, log in, start gnome-tweaks, navigate to the “Extensions” tab and enable dash to dock. From the settings gear icon, select “extend to edge…” and you should have a very serviceable dock that is quite similar to Ubuntu 20.04’s.

Finally, switch the terminal to “Green on Black” for a better look in the terminal. Pin your favorite apps to the dock and you should be good to go.

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
LogFile %LOGFILE%

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

<Extension _syslog>
    Module      xm_syslog
</Extension>

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

<Extension _exec>
    Module      xm_exec
</Extension>

<Extension _fileop>
    Module      xm_fileop

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

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

<Extension _gelf>
    Module      xm_gelf
</Extension>

<Input eventlog>
    Module  im_msvistalog
</Input>

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

<Route 1>
    Path eventlog => out
</Route>

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!

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!

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.

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.