Stefan – Page 7 – Unix Sec Lab

Fun-Day Friday – Food Forest card game

This week’s family game time discussion revolves around a set of playing cards that were initially sold via a Kickstarter campaign. The theme of the cards (and the game) helps to teach Permaculture principles, especially tying elements together to form a system. The decks I received each have 66 cards that are already defined elements with pictures, descriptions, and clear markings for how that element may interact with other element cards. Each deck also contains two “blank” cards so that you have the option to fill in your favorite element, (plant, animal, structure, etc) if it’s not already in the deck. Finally, there were four non-playable cards. One is a brief introduction to the deck with a description for basic card interaction. One card is a “Key” card that explains the symbolism on each card for quick look up. The other two cards explain various games that can be played with the cards. Some of the playable cards are “disaster” cards, with a description of how to handle the disaster if one is drawn.

I bought three decks, initially, so I’m not sure what the packaging is like if you order a deck today, but the only complaint I have about these cards is the packaging. The box is structurally okay, but the flaps were held in place by little “dot” stickers that didn’t hold their sticky. This means the flaps come open fairly easily at either end of the box. I played a game of 72 card pick up when I picked up the first deck from the shipping package, because the flap came open and the cards fell out so easily.

The games that are suggested tend to run along the line of matching cards based on their inputs/outputs. I also like the way that you can pull some pairs and set up games of “memory” for younger players. The cards lend themselves to a variety of game types, if you’re tired of the basic games suggested by the creators.

Similarly to the Wildcraft! board game, these cards are educational, the art is well designed, and the games that can be played are fun.

If you’re interested in these, you can pick up your own deck at the Food Forest Card Game website. The site has dates of “2016” on it, so if you want to be sure that things are up to date, try their FaceBook Page or Karl Treen (one of the creators) on Twitter.

General Rant – If you work for a software vendor read this

Today’s Lab Gear post has been delayed to next week. Hopefully you stick around for this, but I understand if this post turns a lot of people off. Still, I feel strongly enough about this that it needs to be shared.

I have an hour commute to work every day. That means I also have an hour commute home every day. This extra two hours out of my day is often spent chewing on how to deal with work tasks for the week, or what to share on this blog for the week. Today’s drive home was spent fuming, instead.

I will not name the vendor, but we have a product we’ve been wrangled into purchasing due to certain certification requirements we are required to maintain. As such, we went through a small array of vendors for this kind of product, and settled on “The One That May Not Be Named.” All was well and good for the on site product demonstration. We bought the product, and then made arrangements to have professional services on site for installation.

The problem is there were two products purchased. We got two weeks of services. One week was used for the installation of each product. Normally this would not be a problem. In fact, it’s pretty standard practice in the industry to take about that long to get things stood up, configured, and turned over for production. In this case, it was handled poorly.

Over the five day period that the vendor representative was on site, at least four of those were used to do what SHOULD have been done prior to engaging us in person. Architecting the solution.

I think I’ve mentioned this before, but it might have only been in the bonus content email my subscribers get. I’ll say it again, just in case.

My job title at a previous company was Unix Systems Engineer/Architect/Admin. Those are three distinct roles, and most people in this field will wear all three hats. An “Admin” deals with day to day mundane configuration tasks, such as user provisioning (add/remove/modify) and configuration file changes to services such as SSH. And “Engineer” deals with break/fix scenarios, troubleshooting, and engaging vendor provided support when necessary. And “Architect” deals with vendors, end users, and other teams to design and provide a solution that meets the end users’ goals.

This particular company, (The Vendor,) dodged almost every attempt at architecting the solution before coming on site. The end result was that by the end of the 5 day on site professional services visit (for BOTH products… happened twice) we ran out of time to finish configuration. Things weren’t working 100% when the services people got on the plane. Emails to keep them engaged were less than helpful, and a lot of our questions were left unanswered.

Then we ran into a lot of technical issues. Again, these issues should have been identified during an ARCHITECTURE pre-on-site-meeting. This project has stagnated several times, sometimes due to internal company politics at a level or three above my head. This means every time I get the green light to go back to installation, I have to refresh myself on what all has been done.

The Vendor has been on site a few times to try to help make things right with us. They see our frustration (as a customer) and I feel that they honestly want to help, but today I just got a bad taste in my mouth about the whole deal. One person responded to an email with “should we get you on the line to purchase more professional services?” as a response to an email I sent regarding one more technical road block I hit.

I was as polite as I could be in my response, though I fear I still came across a bit caustic.

Part of my frustration is this whole deal feels almost like “The Dale.” If you have Netflix streaming, check out the “White Rabbit Project” season 1, episode 4. In it, they talk about a car called “The Dale.” It was the most hyped car the year it was supposed to be released. Only three were produced in the end, and none of them really worked. While this software doesn’t quite meet that bill, the way it was marketed certainly does. Getting it installed using the custom script that the vendor provided works well, when it works, so I can’t do a direct comparison. When it doesn’t work, though… digging into the guts to figure out why quite literally sucks. It sucks my soul and my give a damn, and I’m running really short on both these days.

I have until the end of this month to finish rolling this thing out. I’ll keep rolling with it, and I’ll keep engaging them as best I can, but the damage is done. I’m less likely to tell people how “great” this vendor is if asked, simply because of how the services for standing this thing up were handled. It’s hard to make things right when there’s a missing limb spurting blood in the mix.

If you work for a software vendor, please, please, PLEASE make sure you review how you engage your customers. Learn about their environment. Let them explain to you how things are done “today” so that you can understand how to help them use your product to make those things easier, more efficient, and better in general. Don’t take advantage of them by sending “professional services” to architect the solution when those services really should be focused on just installing/configuring in general. Don’t be “The Vendor.”

General Rant signing off.

Sudo Policy Fixes and Fails – Importance of auditing your sudoers policy files.

Wait, what? Yes. That is correct. This week is skipping the SSH series to begin discussions on Sudo policy review. We will return to the SSH series soon, but I really, really, really want the next post to cover the use of token devices (using the Yubikey 4 for the first discussion on this,) and I’m simply not prepared for it. I’ve run into several road blocks on getting my new key programmed, all of which will be covered when I write that post.

Since I don’t want to skip a day of content, I decided to introduce the next major topic I’ll go into after wrapping up the SSH series.

Sudo isn’t the only privilege elevation policy engine available. It isn’t even the only open source privilege elevation policy engine. It is, however, one of the most popular, and powerful in its own right. However, it is also one of the most easily misconfigured tools, and this can (and does) lead to very dangerous policy.

For our first foray into what does and does not constitute “Bad Sudo,” we will look at one of the most overlooked utilities provided by the sudo package: sudoedit.

Before we discuss “sudoedit,” we should look at the problem of granting elevated privileges to editors in general.

Let’s start with the classic “edit a file with vi” entry.

Cmnd_Alias EDITFILE = /usr/bin/vi /path/to/file someuser ALL=(ALL) EDITFILE

The user “someuser” now has permission to call /usr/bin/vi to edit the file /path/to/file as root. When this happens, sudo calls the /usr/bin/vi command as the root user. Why is this dangerous? The “vi” editor allows for calling out to the shell to execute commands. You can do this by hitting the escape key, then “:!/path/to/bad/command.”

There is a tag that is often used to try to suppress this command from being able to do harm. The NOEXEC tag can often be seen in configurations where this was attempted.

Cmnd_Alias EDITFILE = /usr/bin/vi /path/to/file someuser ALL=(ALL) NOEXEC: EDITFILE

Unfortunately, this is a bandaid that may or may not work as intended. It relies on interrupting a program that was built with dynamically linked libraries. It also relies on the sudo command itself being compiled with the NOEXEC support built in. If the command in question were “ed” instead of “vi” (or on older systems, “/bin/vi” instead of “/usr/sbin/vi” where “/bin/vi” was often statically compiled so that it could be used to help repair a bad /etc/fstab for boot issues, and /usr wasn’t mounted properly) this would be useless. The tag would do nothing to prevent calling out to the shell.

Now let’s look at the correct way to handle this.

Cmnd_Alias EDITFILE = sudoedit /path/to/file someuser ALL=(ALL) EDITFILE

As you can see, instead of calling “/usr/bin/vi” we call “sudoedit” to modify that file. What does this do? It’s simple. The user will call “sudoedit /path/to/file” instead of “sudo vi /path/to/file.” The sudoedit command will then obtain elevated privilege to access the file, make a copy of it to a temp file, then open an editor for the user AS THAT USER. This means in our example, that the editor will be called as if “someuser” had called it himself. The user can call out to the shell for command execution all day, but it will only run those commands without any more privilege than the user already had.

How does sudoedit know which editor to use? From the man pages:

The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.

So we need to be sure to set a policy of allowing a handful of editors for our users, and then clean up any policy that is granting access directly to editors to fix bad policy. In order to do this, we need to set a Defaults directive to list the available permissible editors.

Defaults editor="/usr/bin/vi:/usr/bin/emacs:/bin/ed:/usr/bin/nano" Cmnd_Alias EDITFILE = sudoedit /path/to/file someuser ALL=(ALL) EDITFILE

This will let users use either vi, emacs, ed, or nano, depending on preference. There is an “env_editor” option, but if it is set, it lets users set any editor they like. This could be something that isn’t actually an editor, so the safe thing to do is just give the list of approved editors in the option I listed, instead.

I will cover some more “gotchas” like this eventually, but I’m hoping I get all of the kinks worked out of my Yubikey adventure before next week, so I can get back to the SSH posts, first.

I hope this was useful to some of you!

Fun-Day Friday – The Classic Board Game (Checkers)

I’m sure everyone reading this has played Checkers at least once or twice. It’s a classic game of strategy that doesn’t require as much mental stress as games like Chess. We’re going to cover it today (and this will be a short post) because a Checker set is a very versatile way to pass the time on a rainy day.

The classic game arranges twelve pieces for each color (red vs. black) at opposite sides of the 8×8 board, all on the same color of square (red or black) so that pieces are diagonal. Each player moves diagonally across the board with the option to jump (and remove) the opponents checkers if the space behind that checker is empty. If you get to the opposite side, that checker gets “kinged” and can now move backward as well as forward around the board.

The next most commonly recognized game with this board is “give away.” This is played exactly like the classic game, except that the object is to be the first player to lose all of the pieces. Also, if a jump can be made, it MUST be made, so a player can set up the opponent to force them to take pieces.

A less common game is sometimes called “fox and hounds,” but the locals called it “fox and geese” when I was growing up, even though that’s technically a different kind of board layout, and played slightly differently. One player places four of the same color checker on the row closest to himself (again, all the same color, and moves are diagonal.) The other player places the other colored checker anywhere on the row closest to herself. The four are the “geese” (or “hounds) and the one is the “fox.” There is no jumping allowed, and pieces are not removed. The object for the fox player is to get to the other side. The object for the geese is to corner the fox until it can no longer move, thus preventing it from reaching the other side. The fox moves like a king, any direction diagonally. The geese move like normal checkers, one direction down the board diagonally. This game is not balanced in the favor of the fox. A perfect game can be played if you know the correct pattern for the geese in chasing the fox. Since this is not a “fair” game, I prefer not to play this often unless I’m playing the fox, to let the other side learn how to develop the strategy (what patterns of movement make a perfect game?) I won’t put the solution for the geese in this post, but if someone strongly wishes to see it, I don’t mind sharing privately. You can leave a comment, and I’ll respond to the email address provided with the solution if asked.

Other names for this game include the word “Draughts.” Board sizes and rules vary from country to country, but the general idea is mostly the same. And there are other games that can be played using the standard 8×8 board. You can even easily develop new games and challenges friends and family, such as “treat a piece like a knight from Chess and without hitting the same square twice, hit every square on the board.” Or perhaps, “treat each piece as if it can move like a queen from Chess, and place as many on the board as you can without being captured by any other piece.” It is possible to threaten every square on the board eventually, but it takes some thought. Set aside a 3×3 section and play tic-tac-toe. This last game is trivial to force a tie. Or play “connect four” by placing your pieces along one side of the board, building out from there (as if they were dropped from the opposite side.) Add your own house rules to the basic classic game. Just learn to think outside the box and make things more challenging over time, and you can find enough different variations on this basic game to keep your mind busy while enjoying time with friends or family.

Sorry this was short and sweet, but this has been a rough week. I will (again) try to get the recording done over the weekend for the SSH CA thing that I keep promising. Hopefully I don’t get overwhelmed with honey-do tasks, and can get caught up.

Thanks for reading, and I hope I have inspired some of you to try new things with an old game.

The Lab – Gear Check – New Arrival (another Bone)

Last week, I obtained a new BeagleBone Black in the mail. This is the newest revision of the device, and it replaces a few components for newer ones. This is the BeagleBone Black Wireless.

Instead of the RJ45 ethernet jack, it has on board 802.11. Instead of the miniUSB it has microUSB for the Host USB connection (the one that you plug in to get ethernet over USB with the 192.168.7.2 address.)

It also comes with a newer version of Debian. Instead of Wheezy (7) you get Jessie (8.) This means it comes with the dreaded systemd software, but that does give one box to bang around on with that monster installed.

Beyond that, this machine is much like the last, and as long as you can find a place to orient the antennas, you should be gold.

The price is higher, but the on board wifi might be worth it. I certainly felt it was worth the purchase to try. So far I haven’t been disappointed.

The same serial cable works for this board as for the Rev C board, so if you need one, use the link from the previous article.

The new board was available as a kit with case, microUSB cable (for the Host USB connection,) and pre-installed antennas for the wifi, plus a power brick (same as the old board) from the same folks that provided the last kit I listed. Here’s the link for the new one.

I will likely do a demonstration of using the serial connection to install OpenBSD onto a microSD card for this machine at some point, assuming the wifi works with this board. I want to play with it some to be sure before I commit to that, though. If not, I’ll likely at least demonstrate on the old board, where I know it works.

Thanks for reading!

SSH Start to Finish Architecture – A Look at Standards Recommendations

Standing up a service, getting a handle on controlling key distributions, and configuring things to make life easier are all great, but there may be restrictions on what you can and can not do in your environment. These are sometimes imposed by outside bodies, not just corporate policy.

For example, Payment Card Industry standards (PCI), National Institute of Standards and Technology Internal/Interagency Reports (NISTIR), and the various governance requirements from Sarbanes Oxley (SOX), ISO 27001, and so on all give broad guidelines for server hardening. Some of them get less broad (more specific) such as the up and coming PCI DSS requirement to have multi-factor authentication. Whatever your requirements, you should get intimate with the policies that define what you must, may, and must not do, whether they are internal corporate policies or broader reaching standards body policies such as listed above.

We’re going take a quick look at PCI DSS today, and briefly also mention NIST IR 7966 which deals with SSH Key Management.

Whether it is required in your environment or not, I recommend at least a good once over of the NIST IR 7966 document. Sections 4 and 5 are useful in helping to understand the magnitude of a poorly designed SSH deployment. For example:

Most importantly, SSH key-based trust relationships can enable an attacker who compromises one system to quickly move (or pivot) from one system to another and spread through an organization—individual trust relationships often collectively form webs of trust across an organization’s systems.

Imagine an attacker gains access to a little used server. A lazy systems administrator generated a public private key pair there, and sometimes uses it to bounce to other servers in the same subnet, but isn’t really supposed to do that. Now the attacker gains root, and rummages in home directories looking for anything juicy. SSH keys are definitely juicy. A quick perusal of known_hosts and attempt after attempt come up gold when testing this private key that was discovered. Because the admin didn’t lock down the public key at the end points, the private key would work from anywhere. The attacker makes a copy for himself, and goes about his business.

Attackers tend to think in “graphs.” Defenders tend to deal with lists of assets. Yes, those are best organized as graphs, but most defenders don’t treat them that way. A “graph” is organized by a “source” asset, a vector (direction), and a “target” asset that can be affected by that source. Trust relationships are graphs by nature. “Tom” on “Workstation_A” can log into “Tom” on “Server_B.” But “Tom” on “Server_B” can’t log into “Tom” on “Workstation_A.” The trust is one way. Some trusts will be bidirectional. Mapping these trusts is how attackers are able to plant deep roots into a compromised network.

As for the PCI requirements mentioned before, a new requirement is coming that sets up a policy of required multi-factor authentication. In the Scoping and Segmentation guidance document, we can find an example of using a Jump Box for accessing the sensitive systems where we don’t want to apply multi-factor authentication directly to those systems. That jump box is required to run its own firewall as part of hardening of the system. This is called a “bastion host.” The systems administrators are heavily restricted in how they can manage that host, per the rules laid out. An excellent example of a company that is already doing a Jump Box work flow utilizing SSH Certificate Authorities that get generated via the work flow is brought to us by Facebook.

This article shows how they are using it to meet these PCI (or similar) requirements, but are still able to maintain a high level of efficiency in their daily administrative tasks. Pay close attention, because they also talk about “zones” in their set up. You may or may not want to try something similar if you need to stand one up for your company.

Another requirement from that same PCI document is for ONE of the authentication factors to be “something you have.” It requires some kind of security token. I’ve used several in my career. Some are as simple as “my phone” using a one time pad software app. Other have been as complex as a RADIUS token that kept a one time pad for each VPN login session.

Since I’ve been researching how to best incorporate tokens into an SSH deployment, I settled on making my first purchase for the lab a Yubikey 4. It arrived in the mail over the weekend, and next Monday will cover how to get it working for ssh public key authentication.

I also want to take the time to thank 0ddn1x and TechRights for the recent pingbacks. I meant to include a shout out last week, but I was up late, got frustrated with the recording situation, and frankly, forgot.

The new recording should be available this week. (Probably Tuesday.)

Fun-Day Friday – ION (card and dice) Game

Today we’ll cover a game that is kind of odd, but lots of fun. It’s both a card game, a dice game, and a dominoes game, without the dominoes: ION.

There is another card game by the same name from a different company. That one focuses on building chemical compounds using ionic bonds. It looks like a fun and educational game, but we don’t own that one, yet. That will likely change, and a review will be forthcoming if it does.

This ION game contains cards that are printed with dots, much like dominoes. A certain number of cards are dealt to each player at the beginning of the game, and a card is placed face up in the middle. To play a card, the card being played must have the same dots as either half of the face up card. For example, if the card on the table has 3 dots on top, and 5 on bottom, you would need a card with either 3 dots or 5 dots to play it. This is where the similarity to dominoes ends.

There are also “Joker” and “Double Joker” cards, which act as a wildcard, and can be played at any time. Some of the cards are “action” cards, and do different things depending on the icon. They usually involve punishing other players by either making them draw, preventing them from playing on their next turn, or similar. The objective is to be the first to get rid of all of your cards.

One of the action cards is called a “bomb” and should only be used in “tournament” play (where you are keeping score, not just playing to be the first to lose all cards.) This one “explodes” a player kicking them out of the game.

One of the cards is a “challenge” card. This one forces a roll of the yellow die. There is a gamble involved where the person playing this card gets to pick 2 numbers, and the person being challenged gets to pick 1 out of the remaining numbers. Rolling one of the chosen numbers results in drawing more cards. You take turns rolling until one of you gets it.

Some of the cards actually have “punish” in the name, and those require the player being punished to roll the black die. The number of dots on the roll determine how many cards to draw.

There is a “block” card that can block some things, but not others. Usually this is determined by logic of who goes next, but the “gift” can’t be blocked simply “because it’s rude to decline a gift,” according to the rules.

A two player game removes all “punish previous player” and “tick tack” cards, and players are dealt 9 cards to start. Games with three or more include all cards and players are dealt 7 cards to start.

If you like games similar to UNO, this will probably hold some appeal. It can be fast paced, or in tournament mode, it can take a while to play.

The game hasn’t been on sale at this link since December, but in case it comes back, here’s the Amazon link.

The game website is here, in case it eventually has links to other product providers.

I hope everyone has enjoyed the game review series thus far.

Thanks for reading!

The Lab – Gear Check – The Proxmox Server

This week I’ll be brief. No pictures to go with this, because the gear is hand me down desktop stuff, but I’ll share some resource links for the software.

One component of this lab is a virtual machine server that I use to spin up VMs for various things. Mine is currently just an old Alienware desktop I got from my cousin when he was cleaning house a year or two ago. It doesn’t have much, and the setup isn’t ideal, because it’s just one machine, not a cluster for high availability, but it works for a lab environment.

The host software I use is called “Proxmox” which is a debian based Linux distribution that borrows a kernel from RedHat land for some of the capabilities it offers. It’s basically a pretty web based front end to KVM, built in. The interface isn’t too far different from VMware’s VSphere interface, but that’s a simplified comparison, really.

A friend from my old place of employment introduced me to Proxmox, and while I was researching the software online, I came across a book on it. If you already have a hypervisor available, great. Use what you know. However, if you’re looking for an easy to manage hypervisor, because workstation virtual environments like VirtualBox just aren’t cutting it any more, this is a good one to pick up. I highly recommend it. It does have a free version, and it will nag you about not having a subscription, but it’s a minor annoyance in my opinion.

The software can be found here.

The book I mentioned can be found here.

The second edition of that book (which I don’t own yet) is here.

SSH Start to Finish Architecture – Standing up the CA pt 2

Last week we covered most of the explanation and commands for standing up the SSH CA. This week, we will cover the Key Revocation List (KRL) and how to inspect the generated certificates. We’ll also include an asciinema demonstration of the process. Let’s get started.

When you generate the certificate, one of the flags lets you create an window of validity for the certificate. This is more than an expiration date, because it also includes the date that the certificate first becomes valid. This is a great way to create certain user certificates, because you might only want to grant access for a user for four hours over the weekend, and you can issue the certificate during the work week, but it will only work when the begin date/time is reached, and cease working when the end date/time is reached.

Now let’s assume that you issue certificates for a duration of one year at a time for regular employees. An employee is issued a certificate that becomes valid as of the first of February of the year, which means it would need to be re-issued by the next February. If the employee changes job roles and no longer needs access to the same sets of servers, that certificate is now a problem. They have access to systems they should not, and there is a need to revoke that access. In order to do that, we are supposed to use a Key Revocation List.

The KRL is created by the USER CA in our example, and must be distributed to each host each update. This distribution facility is much like managing authorized_keys files, which means it can be cumbersome. It is at least management of just one file, but that’s still one file more than ideal.

From the sshd_config man page:

RevokedKeys
Specifies revoked public keys file, or none to not use one. Keys listed in this file will be refused for public key authentication. Note that if this file is not readable, then public key authentication will be refused for all users. Keys may be specified as a text file, listing one public key per line, or as an OpenSSH Key Revocation List (KRL) as generated by ssh-keygen(1). For more information on KRLs, see the KEY REVOCATION LISTS section in ssh-keygen(1).

Okay. Now to check ssh-keygen man page:

ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs). These binary files specify keys or certificates to be revoked using a compact format, taking as little as one bit per certificate if they are being revoked by serial number.

serial: serial_number[–serial_number]Revokes a certificate with the specified serial number. Serial numbers are 64-bit values, not including zero and may be expressed in decimal, hex or octal. If two serial numbers are specified separated by a hyphen, then the range of serial numbers including and between each is revoked. The CA key must have been specified on the ssh-keygen command line using the -s option.

Remember last week when we said a serial number was needed for the KRL? This is why. The user generates their keys. They send you their public key for signing. You sign the key to generate the certificate, and ship them the certificate. The correct thing to do at this point is to delete your copy of the public key AND the issued certificate.

Now that person had a breach to their workstation, and the key should not longer be trusted. You can’t just let the certificate expire naturally. This person had a highly privileged role, and you want to be SURE the authentication is fully revoked, but only for this one certificate that was issued. You need to issue a KRL statement, but you don’t have a copy of the actual certificate or key to revoke. In this case you need to revoke by serial number.

The serial number is supposed to be unique, so it is a good idea to create the serial number from a scheme. You might consider something like “a UID number + some base range.” If the user’s UID is 2352, and you settle on a base range of four digits, for example, the first serial would be 235320001. This would get incremented each time a certificate is issued for that user. Alternatively, log the serial number into a database for each certificate issued, so that it can be searched for quickly. Whatever works best.

When it comes time to revoke all certificates a user may own (in the case of multiple valid certificates) you can also revoke by ID.

Remember, when generating the certificate, the “-z” flag is for the serial number, and the “-I” flag is for the identity. When revoking a certificate, you will use the “-k” flag as shown below:

ssh-keygen -s <ca_key> -I <certificate_identity> -u -k ssh-keygen -s <ca_key> -z <serial_number> -u -k

The reason we also provided the “-u” flag is that it updates the KRL rather than replacing it. This means we don’t accidentally remove other revocations that should still be present.

What are some of the problems with this solution?

If we tell the server to use a KRL, the file must exist, or sshd will not start. This means an empty file must be there if it is configured to point to a KRL file, but there are not keys to actually revoke. If a systems administrator unfamiliar with this removes the file because it is empty, in an attempt to clean up zero length files on the system, it will break sshd on the next restart.

The KRL needs to be managed on a per end point server basis. This is much like the problem of handling individual authorized_keys files per server. The reason I specifically mentioned the serial number issue is to pinpoint a scenario where we are not revoking access for a specific user because they are no longer here, but to revoke ONE certificate for that user because of a breach.

There are several ways to deal with the KRL situation. You could create a script that pulls the KRL from a single site and stick it in a cron job. You could use an rsync process to push it out to multiple end points every time the file is updated. Neither of these is ideal, but I do NOT recommend doing something that seems easy, but might cause nightmares in the wee hours of the morning one weekend for some unlucky oncall engineer. Do NOT point the configuration to a network enabled file share. If the share were to fall out, the file would no longer be there in the eyes of the sshd, and if nobody noticed, the next service restart (say, by a late night automated OS update) sshd would refuse to start. You might consider having a network share, but use a script that regularly checks for file to be updated before copying it into place locally. Whatever you choose, the solution isn’t going to be pretty.

One more note about KRLs. You can test if a certificate or key is in a revocation list with the “-Q” flag to ssh-keygen.

ssh-keygen -Q -f <KRL_file> <key_or_certificate_file>

And this is a good time to transition to inspecting certificates. In order to inspect a certificate, use the ssh-keygen “-L” flag.

ssh-keygen -L -f <key_or_certificate_file>

This is what an example file looks like:

$ ssh-keygen -Lf ./.ssh/id_rsa-cert.pub ./.ssh/id_rsa-cert.pub: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT 04:29:a8:fd:55:04:db:8f:1e:0d:45:18:a7:8e:a7:a6 Signing CA: RSA 27:cc:19:a3:67:1b:5e:2e:6a:48:a9:25:25:6d:64:6c Key ID: "root" Serial: 1234 Valid: forever Principals: root Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc

There was going to be an Asciinema recording. I went through the whole sequence until it was time to log into the target server. I generated a certificate from 2014 because the date/time of the beaglebone is off by that much, and now it’s past midnight. I will re-do this work and upload at a later date after correcting the clock issue on the demonstration CA machine.

I apologize for the lack of a recording at this time. Thanks for reading!

Fun-Day Friday – Settlers of Catan

This week we’ll cover a board game that is tons of fun to play, but takes a lot of time. This is a good rainy day family fun day game, so if you’ve never heard of it, read on.

The Settlers of Catan game includes a board that is dynamic. The pieces that make up the board can be put together like a puzzle, but they’re mixable so you can move where each little land plot can be placed. The instructions include a recommended default layout for beginners, and it is highly recommended to follow it, since it gives a good balanced layout of lands around the board.

First you build the outer border (which is supposed to fit together the same way every time, with number tabs/slots that connect.) Then you place hexagonal land pieces inside like a honey comb. Once the whole board is laid out, you place numbered tokens on each land.

A “robber” piece goes on the desert land.

Each player picks a color and takes 5 settlements, 4 cities, and 15 roads. Each player places two settlements and two roads on the board to start. A settlement goes on the corner of one of the hexagonal shaped land pieces, and a road runs long the edge of the hexagonal land piece. Each land that a settlement touches allows that settlement to potentially obtain whatever resource it can produce in a round.

A round begins by rolling the two six sided dice “for production.” The roll applies to all players, not just the person rolling the dice. Whatever number is rolled determines which lands may produce resources that round (based on those numbered tokens that got placed on each land.) Any settlement on the corner of land that produces that round gets a resource card for the resource that particular land produces. Rolling a 7 is special, and we’ll get to it in a bit.

After rolling for resources, the player that rolled the dice may trade resources. There are two kinds of trade. Domestic trade allows the player that rolled the dice to trade with the other players on negotiation terms. The other kind of trade is maritime trade, and allows for “trading” resources without trading with other players. The normal (and worst) maritime trade is a 4:1 ratio. A player may turn in any 4 of one resource card in exchange for one other resource card. If the player has a settlement on the outer edge of the island next to a harbor, the harbor allows for maritime trade, which has more favorable ratios.

Once trading is done, if any, the player that rolled the dice may build. Building costs are dependent upon “building cost cards.” Refer to the card and spend the appropriate number of resources to build a new settlement or road, or to upgrade a settlement to a city. You can’t build a settlement on an unoccupied intersection if any of the adjacent intersections contains a settlement or a city. This means you can’t ever have more than three settlements/cities on one hexagonal land piece. You also have to build the new settlements along one of your existing roads. You can also spend resources to obtain a “knight card” or a “victory point” card.

A special “longest road” and “largest army” card are set aside until someone earns them. To earn the “longest road” card, you need to be the first to build a continuous road of at least 5 individual road pieces. After that, it can be stolen by someone else if they build a road that is longer than yours. The “largest army” card is earned by becoming the first player to earn three knight cards. Anyone earning more knight cards than you will take it, later. Each of these cards is worth two victory points for the holder of the card.

To put a damper on things, there is a robber in the desert. Any time someone rolls a “seven” several things happen. First everyone with seven or more cards must discard half of them (odd numbers rounded down, first.) Next, the player that rolled the seven must move the robber to the number token of a terrain hex, or back to the desert if it’s already on a terrain hex that isn’t desert. Finally, that player is allowed to steal one resource card from one player with a settlement next to that resource hex.

If a player plays a knight card on their turn, they move the robber as if a seven were rolled and attempt to steal a player resource card. The player being robbed places his cards face down and the robbing player picks one at random. If the robbed player has no cards, nothing is stolen.

The first player to reach ten victory points wins. Points aren’t awarded each turn, they are counted based on what the player holds.

Settlement = 1 VP each
City = 2 VP each
Longest Road card = 2 VP
Largest Army card = 2VP
Victory Point card = 1VP

This game is complex, and play time can reach or exceed the time it would take to play a decent game of Monopoly (for comparison.) It does help develop strategic thinking, though, and does so with an excess of fun.

I’m sorry this one ran a bit long, but it is what it is. Thanks for reading!

The Game is available at Amazon, and probably other retail outlets.