Remote Desktop and the MSTSC Workstation

I had a fun adventure recently. It actually started towards the end of 2017. A client was having a couple of their Active Directory accounts locked out in the wee hours of the morning. I didn't work on this problem at first, as this was a client of my friend's business. Until very recently, I worked regular 9-5 jobs until I figured out that I'd rather be working for my friend instead. But that's another story.

Story Time

My friend had spent a number of hours troubleshooting this issue, but it was hard to nail down when it was going to happen. Impossible, really. Eventually he couldn't keep having the client locked out, so he ended up making new login IDs for the users that were being locked out, and went on about his life. And that was the end of that.

Until about a month ago when the problem came back with a vengeance. Now something like 4 or 5 accounts were being locked out, and now I worked for my friend. In his business I have, by far, the most experience with Active Directory. I'm no fully fledged AD administrator, but I know a few tricks.

The first thing to do was enable logging on the domain controller. Because of course there's only one. Once that was in place, we could actually see the name of the workstation that was causing the lockouts. MSTSC. Well, that's obviously a bum name. I was hoping to get an IP address.

I looked around the internet to see if I could find any references to other people having this problem, and to see if I could find a penetration testing script that would also spoof the workstation name. I did find a script that would attack RDP, but it doesn't (from what I can tell) spoof the machine name.

But more importantly, I happened upon a thread regarding this issue. Several people were talking about this issue, and the things that they all had in common were:

• They all had RDP listening on the filthy, unwashed Internet
• They all thought that RDP listening on the filthy, unwashed Internet was an acceptable form of remote access for a business

I had to check the date the original post was made. Sure enough, in the year of our lord, 2018, we can still find people putting RDP naked on the internet. I mean, this is a process that I think many techs go through, right? You discover how to forward a port, and suddenly you have access to your network via RDP. Oh hey, you can spin up a Linux box, and tunnel that RDP session! Oh wow! You can just install OpenVPN!

Big, Damn Rant

But never before have I encountered such hostility to the mere idea that putting RDP on the Internet was a bad idea. It basically boils down to, "Getting users to understand and use a VPN is haaaaard!" Waaaaah! There is someone out there on the Internet right now that has one or more valid login IDs to your network! How are you so calm in your defense of this objectively terrible practice!?!

And really, some unknown entity out on the Internet having a valid login ID to your network is kind of a big deal. First, they're only a password away from logging into your network. Second, locking out users from being able to use their computers is an attack on your network specifically! This is significantly different from someone who just happened across your IP address, and decided to stroll down a list of common login IDs. Take it seriously!

The way I see it is similar to crypto viruses and HIPAA compliance. If a document with patient health information is encrypted by a virus, you have to report that as a breach, because you lost control of the data. Doesn't matter if you're using ZFS (and you damn well should be) and you can rollback within seconds. You lost control of the data, report it.

I would argue the same should be true for accounts that you lose control of. Not when a user enters their passwords incorrectly too many times, or something like that. When an account is locked out, and it's by an entity outside of your company's control. That should be something that gets your hackles up every. Goddamned. Time.

Back to the Story

Well, I had ruled out RDP near immediately. A few years back, this company actually had been breached, and surprise surprise, it was because RDP was used as remote access. After that breach they moved to VPN for remote access. As with any assumption, it took me longer than it should have to question it.

This client actually has 2 offices, with a site-to-site VPN between them. When they converted away from naked RDP to VPN, they closed the RDP port forwarding at one office, but not the other. At the second office, a lone desktop sit listening for connections from the internet. That was the source of the attempts.

Back to the RDP Defenders

One of the people defending RDP on the Internet wanted to understand how an event with a clearly false hostname is generated. If you're also wondering, wonder no longer.

I can replicate such an event. I spin up a VM, and I give that VM the name MSTSC, I lock out an account, and I get an event log message stating that the workstation MSTSC has locked out an account. I'm not suggesting that there are hundreds or thousands of computers out there named MSTSC. I'm suggesting that you're being General Hux'd.

Most likely, there's some script out there for attacking RDP that became popular who knows how long ago. Part of that script's claim to fame is that it also spoofs the workstation name. And whoever wrote the script originally chose the name MSTSC as the default spoof.

Maybe they did it because they thought people would fixate on it, thinking that Windows was broken and just giving them the name of the application that locked the account. Or, since mstsc.exe is the name of the typical Windows remote desktop client, maybe they just had MSTSC on the brain when they wrote the script. Naming things is one of the two hard things in programming, after all.

What do I Want You to Take Away From This?

I want to put it out there that it is not acceptable to use RDP naked on the filthy, unwashed Internet. I don't care how small your company is. I don't care if you don't think there's anything to steal (you'd be wrong about this, btw).

Learn how OpenVPN works. It's actually not that hard. I feel like people are just wary of it because it involves security certificates. Really, it's not that scary, and the client for Windows is actually really nice. Better, I would say, than the most, if not all of the other VPN clients I've ever used.

If you are in a thread where you and lots of other administrators are talking about user accounts being locked out by outside actors with the exact same evidence, be open to the idea that you're all doing something very wrong.

Proxmox, ZFS, and Memory.

I've run into a really interesting issue with Proxmox and ZFS. This is a scenario where Linux's goal of caching everything and its dog really bites us, because it doesn't really seem to play well with the ZFS ARC.

ZFS, ARC, and VMs

For those not in the know, ZFS is the Zettabyte File System, I highly recommend it, as it is awesome. The ARC is ZFS's read cache, called the Adaptive Read Cache. Great, with that out of the way, what was happening?

Well, first off, I got some really bum advice from the Internet at large. That happens from time to time. We have been having performance issues with our VMs for a while, and a knowledgeable source suggested dropping the ARC max to comically low levels. Why? Because "you don't need it for virtual machines."

The idea is that your guest OS will do its own caching, and so you don't want to cache twice. Okay, I'll buy that for a moment. If a Windows guest gets a request for a file that Windows already has cached, it's not going to go to the virtual disk for it, and as such it's not going to hit the ARC even if that file is in the ARC.

Good theory! Except for the fact that it's terrible. For those who haven't read up on the ARC, the ARC is amazing. Basically every operating system and RAID controller, and whatever else that uses cache uses a first-in-first-out caching method. This has long been considered a dumb way to cache data, but no one has bothered to come up with a better system.

Enter the ARC. The ARC caches blocks of data based on interesting bits of information like how often the block is accessed, or how close the block is to other blocks that are commonly accessed. Basically, the folks who made ZFS put in a good effort to predict which blocks are going to be useful to have in memory, and as it turns out, that effort was well worth it because it blows FIFO out of the water.

With that little nugget in mind, don't drop the ARC max! That's crazy talk, and you will immediately regret it. The ARC is your friend.

ZFS ARC Min/Max

Now, best I can tell, if you don't manually set the ARC max, the ARC will increase in size as it's needed. I think the default ARC max goal is 8GB (the goal being what it tries to achieve, assuming there's no other pressure on memory). As pressure on memory increases, the ARC will shrink. It's very selfless like that.

What I didn't realize would happen from setting the ARC max to a comically low setting is that this put ZFS at a disadvantage with Linux also trying to cache data from the file system. Kinda makes me wonder if it's a bug, actually.

As VMs would pull data from disk, Linux would attempt to cache the data itself, as did the ARC. Well, Linux caching data was apparently seen as pressure on memory as far as the ARC was concerned. So the ARC shrank, and shrank, and shrank until it got down to about 50MB in size. At that point the whole system would lock up pretty hard.

Lo and behold, there's an ARC min setting. I've never had to set that before. Well, I never had to set the ARC max before either.

If you need to set the ARC max, make sure you set the ARC min as well.

You can find these settings on Linux in /sys/module/zfs/parameters/zfs_arc_max and zfs_arc_min. Or set them in /etc/modprobe.d/zfs.conf

options zfs zfs_arc_max=1342177280
options zfs zfs_arc_min=1073741824

 That will give you a max of 10GB and a min of 8GB. No matter the pressure, the ARC will stubbornly refuse to shrink below 8GB. 

DOSBox 0.74-4.2

In my previous post I walked through how to get X-Com Terror From The Deep running in DOSBox in Linux. Well some people ran into an issue running it. The reason was actually a bug in the latest version of DOSBox.

The way this presented itself was a person could launch TERROR.BAT or TERRORCD.BAT, and then the game and DOSBox would crash.

In order to get an error message, we could launch DOSBox from the command prompt, rather than from the GUI. This got us the following error.

Exit to error: DRC64:Unhandled memory reference

A handy message that lead me to this thread,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857341

It seems one of the options to fix this issue is to downgrade your version of DOSBox, at least until 0.74-4.3 becomes available. Another option is to change the core setting in your DOSbox configuration file.

I was able to change it from core=auto to core=simple and run TFTD without issue.

Linux, GOG, and Windows-only DOSBox Games

I wanted to create a quick guide on how to get DOSBox based games from GOG running in Linux. I've seen in a number of places now people just downloading old, DOS based games that are supposedly Windows-only, and just running them in Wine. The problem here is that you have Wine's kind-of-emulation layer, and then you've got DOSBox's emulation layer. You're not going to have a good time when you do things this way.

First and foremost. The reason that GOG lists some DOS based games as being Windows-only is simply due to licensing. GOG has contacted the companies that hold the IP to these good, old games and asked for permission to re-package them with a DOSBox executable for Linux, thus making them available for Linux. This has had a lot of success, but there are still a lot of old DOS games that are listed as Windows only.

The example we will use here is X-Com Terror From The Deep. With Steam tracking how many hours I spend in games, a lot of my friends see that I've spent a couple hundred hours in a game and go, "Woah! You spent a lot of time on that game." Naw man. You don't even know the addictions that were X-Com Terror From The Deep, and Ultima VI The False Prophet (Ultima Dragons, sound off!). But I digress.

Configuration!

Applications that you will need in Linux:

Wine

DOSBox

If your liver is already itching at the mere mention of Wine, don't worry, we're not going to use it for much. Once you have these installed, hop into the terminal and run the following commands.

mkdir ~/DOSGames

winecfg

The first command, the mkdir command, will create a new directory in your home directory called DOSGames. If you're not familiar, in the terminal ~ tells the command interpreter that you're talking about your home directory. This way you don't have to type out /home/myusername/DOSGames. We'll use the DOSGames directory with the next command.

The second command will pop up a new window for configuring Wine. This gives us our initial Wine configuration, and also while we're here we will hit up the Drives tab. What we want to do here is add a new drive, D:, and point it to ~/DOSGames.

What this will do is allow any DOS based game that we install via Wine to be installed directly to ~/DOSGames. Here's about what it should look like.

Go ahead and click OK at the botton. 

Installation!

Now we will use Wine to install X-Com. Now, often when you install Wine, you get a context menu option so you can just right click on the installer you downloaded from GOG, and select Run With Wine. If you have this option, awesome! If you don't, you should be able to open up a terminal and navigate to the directory with the installer and run Wine manually.

cd ~/Downloads

wine ./setup_xcom_terror_from_the_deep_2.0.0.4.exe

And at this point you should be looking at an installer for X-Com! Woooo! A couple of things to point out, however. You'll want to hit the Options button so that we can tell the installer where to put X-Com.

I've missed it on this particular install of the game, you can see I'm still installing it to the C: drive. You'll want to install it to the D: drive. I would highly recommend a path like this.

D:\XCOM2

This will make more sense once we actually get into DOSBox. Once you've told the installer what path to install to, and clicked the EULA check box, go ahead and click install and wait for the file copy to finish. You will likely get a bunch of error messages at the tail end of this process. Don't worry about them, just click through. You probably do not want any desktop icons for this, as those icons would launch the game via DOSBox via Wine, and then you will be sad. If you did have it create desktop icons, you can just delete them.

DOSBox Configuration

First, I want you to launch DOSbox. There should be an icon for it in your GUI. If you can't find it, you can launch a terminal and run the command,

dosbox

Pretty easy. But we're just launch it so that it will create a configuration file. When you get the DOSBox window, go a head and type exit to close the window. Now open up your file explorer and hit CTRL+L to open a specific location. This will give you a bar across the top with your location in the directory structure. Like you are at /home/yourusername. Just tack on /.dosbox/ at the end so it looks something like this.

/home/yourusername/.dosbox/

And hit enter. You should be looking at a directory with a file named dosbox-0.74.conf. Go ahead and double click that file, it should open with a basic text editor like gedit. Scroll all the way down to the bottom. There should be a section called [autoexec]. Under that section you want to put the following.

mount c: ~/DOSGames/

c:

Now every time you launch DOSBox, it will automatically make that DOSGames directory your C: drive, and change to that drive. Let's launch DOSBox again.

In my example I used X-COM-TFTD as the directory that I wanted to use. If you're not familiar, DOS used an 8dot3 file naming format. 8 characters for the actual name of the file, and 3 characters for the extension. When a name goes beyond 8 characters, it presents the user with the first 6 characters, and then ~1. If I had a similarly named directory, it would increment to ~2.

From here you can use the cd command to change directory to X-COM-~1, and then run terrorcd.bat to run the game. Or you may have to run setup.exe first to setup your audio hardware and all that good jazz. But that gets beyond the scope of this.

I just wanted to show people that there is a way to get "Windows-only" DOS based games running in Linux, and that you can also put them all in a convenient directory. For every new "Windows-only" DOS based game that you want to install, tell it to install to your D: drive, and you will see it when you fire up DOSbox.

If I can muster up the willpower, I will create a post on how to create a convenient menu in DOSBox for launching these games.

PuTTY Copy On Right-Click

PuTTY is one of those tools that everyone seems to know a little something about. In general, I prefer to just work from a Linux based desktop, but all too often I find myself back on a Windows box needing to ssh somewhere. PuTTY becomes a good tool for this because you can download the standalone executable and just use it.

I recall a time many, many moons ago, when I was making an attempt to transition from primarily Windows on the desktop to primarily Linux on the desktop. One of the features I sought after for some time was a way to paste on right-click in the terminal, just like PuTTY. Oh familiar PuTTY.

If you tried to configure my Linux desktop that way today, I'd probably slap you silly. That is by far the most annoying, and incidentally the most dangerous feature of PuTTY.

"SURE! Just paste whatever happens to be in the clip board into that terminal window! It's cool. I'm sure it's not actually a command, and you're probably not logged into a production server anyways. Right?"

I use Linux at home these days, but when I go to work, they want me on a Windows box. Okay. PuTTY it is. But I'm turning off that goddamned paste feature! Here's how you can do it.

In the PuTTY Configuration screen, in the left menu tree, select Window -> Selection.

By default it is set to "Compromise (Middle extends, Right pastes)." These days I vastly prefer "Windows (Middle extends, Right brings up menu)."

This basically does what it says on the tin. When you highlight something, it will still automatically put that data in the clip board, but now when you right-click, it will bring up a context menu. In that context menu, Paste will be an option.

Boom. Your days of accidentally pasting awkward bits of emails into production command prompts are now over. Make sure you save this as the Default Settings session so that you don't need to change it with each new session you create.

Lots of love to the folk(s?) who maintain the PuTTY tools. To me, these tools are basically the gold standard by which all other such tools in Windows are judged.

Remmina Resolution

Just dropping in for a quick update. I've worked with a number of remote desktop clients in Linux, and one that has stuck with me for some time now has been Remmina. Some of my friends have asked about how I deal with resolution in Remmina and choosing between fullscreen and weird, crappy resolution.

I set the resolution I want, of course.

When you fire up Remmina for the first time, it creates a .remmina directory in your home directory. In there is remmina.conf. While Remmina is not running, edit that file, find the line labeled "resolutions=" and add your desired resolutions. Clean up resolutions you won't use, as long as you're at it. Here are the resolutions I have.

1024x768,1440x900,1920x1080

It's important to make sure that Remmina is not running, and that it's not hiding out in the system tray/task bar/whatever, as Remmina will write out the config file again when the program exits.

EVGA UV+ 39 in Linux

This is yet another quick post. A while back I had purchased an EVGA UV+ 39 USB 3.0 DVI/HDMI adapter thingy. It's a cool little device if you need another monitor and it works great. I couldn't get it working in Linux initially, but eventually I woke up an ran lsusb on it.

Bus 001 Device 020: ID 17e9:4300 DisplayLink

Oh hay, look at that! It's a DisplayLink device. Well, I'll not sport with your intelligence any further. If you're looking for Linux drivers, the drivers here will work.