STE VE CASSIDY
Steve laments the process of choosing remote access software, and uncovers a web page that was disrupting a small business’ net connection
Steve laments the process of choosing remote access software, and uncovers a web page that was disrupting a small business’ net connection.
The remote access business has been presenting itself as an extra layer of security for quite a while, with heavy emphasis on the short time between availability and successful attack. I find such claims overwrought, although I did come across one customer who loved the idea of using shortcuts to start RDP sessions so much that he left a shortcut on a machine in an internet cafe somewhere in Spain. On that occasion, the interval between availability and attack was about as short as the security gurus expect. That is, 20 minutes after the customer finished his latte and walked away.
So, there’s a heavy emphasis on security. People are told to protect their remote connections, and that heavier encryption equates to longer intervals between successful attacks. In practice, this isn’t always the case. Either your machines are infected and the hackers find that your resources aren’t valuable, or you’re simply hiding in an unfashionable corner of the remote access marketplace, where the mainstream, fashionable hackers don’t go.
I can remember back in the days when we went years between RDP attempts, with the rather sad observation that when the attack traffic came from countries in South America, the passwords they’d be trying for the administrator account had distinctly Latin American roots. Yes, it’s smart to try breaking in using girlfriends’ first names; it isn’t smart to choose those names from a list in your native language rather than that of the country you’re targeting.
Back to remote access security. You have the choice of a separate login password, and then an admin password to get into the servers supplied by the server OS, if you want to work on the assumption that neither single password is enough. Everyone believes this is a good idea – except Microsoft. While the independent players have been adding on layers of auxiliary capabilities, such as inter-machine text chat, file transfer and even support for smartphone access, Microsoft has been meddling in the market. And not in a useful way.
Of course, it takes two to tango. For every genuinely dangerous security hole in the OS, there are a million ill-informed experts who blether on about imaginary or misheard vulnerabilities, all of which add up to decades of screaming that the sky is falling when nothing of the sort is happening. Nonetheless, there’s obvious discord between the Microsoft insiders, who point to the proven rates of infection, and the outsiders, who point to standardscompliant VPNs and networks that don’t get infected much.
That said, it was Microsoft that blew up a broad range of small-tomedium-business-sized VPNs. Not once but many times with the
approach to security taken by Windows 10, interfering with the little add-on apps responsible for connecting the roaming device to the VPN’s gateway. It’s also Microsoft that rolled out IPv6 quietly, and then made its DirectAccess server remote access product depend on it.
If it ain’t brokered, don’t fix it
DirectAccess is nearly perfect. It certainly shows signs of having been designed by someone familiar with IPv6, although I wish one could say the same for the team writing the implementation wizard!
If you and your laptop want to be part of a wider DirectAccess implementation, and be findable by all the (appropriately authorised) corporate support resources to boot, then someone running the DA setup wizard needs to factor that possibility in up front. Why? Because by default the wizard uses an IPv4 DNS record format. Manual editing becomes necessary, just at the point when those who are setting this up for the first time are at the limit of their expertise. This isn’t something you just do at 4pm on a Friday.
The difficulty is, how do you make a connection to anything in IPv6, when your laptop is propped up on the wet bar at Mar-a-Lago? The Wi-Fi is IPv4. It’s like an uncrossable chasm: all that IPv4 hardware between you and your distant server doesn’t have the capability to understand an IPv6 address, and your PC can’t take part in your corporate setup without login information, policies, profiles and DNS configurations – all of which Microsoft would like you to be keeping these days in IPv6. Deadlock, surely.
Not quite. There are network standards that allow you to package up your IPv6 traffic and send it to an IPv4 address, where a broker process unpacks it and sends it on to the identified target. That’s the job of a tunnel broker, and you can buy a membership for one of those services off the shelf.
If you went shopping with Microsoft for such a thing, then first you’d become lost in the swamp of over-extended product names, long implementation delays and halfhidden documentation. That sounds depressing, I know – but did you know that Microsoft only made IPv6 available within Azure in late 2016/ early 2017? So any prospect of an all-DirectAccess environment would be a bit of a configuration challenge, to say the least.
The most famous tunnel broker is probably Hurricane Electric. It’s been offering single users such capability, for free, for over a decade. It gives you global capability to jump from IPv4 to IPv6. But here’s the oddity: it isn’t an encrypted connection.
Let’s mull that one over. Not only do you have to log into a tunnel broker with some credentials, you’ve then got to open up a firewall link to the public-facing side of your server farm (cloudy or on-premises) and then give that a username and password. This then traverses an unencrypted link before your firewall VPN session (assuming you can find such a thing running in IPv6 without breaking the bank) starts up and lets you in to your servers... which then want you to log in with a username and password.
Even if you manage to combine the firewall authentication with the server login, you’re still asking users to run twice the regular password count – and the middle one (of the actual three in use, just to keep things confused) is transmitted in clear text.
Just to make sure I had this right, I called on Alex Bloor, CTO at Andrews & Arnold, a UK ISP that seems to live very happily in IPv6 world. He confirmed that he had a product that works in a similar way, making an L2TP tunnel and then allowing traffic out into the IPv6 traffic stream. He doesn’t encrypt that initial channel either, because to him it makes no sense. Any encryption, he said, is handled further up the protocol stack – say, in the HTTPS connection to the various login portals. It isn’t automatically the responsibility of the lowest-level protocol. Besides, it might break other uses of port 443 in the connection.
Even though the logical case for tunnel brokering in mixed IPv6/v4 deployments remains as strong as ever, and can only go in one direction as IPv4 addresses become harder to come by, there’s no reason to assume that the style of connection offered by DirectAccess is the last word in VPN connectivity. As we’ll see, because Microsoft has pretty much left DA alone ever since the release of Server 2012. Even though DA’s roots go back to Server 2008, one would have expected such a system component to have been updated and improved in a decade of use. Instead, it’s all change.
“It looks as if Microsoft can’t settle on the role it would like to occupy when it comes to roaming devices”
Always-on VPN muscles in
Incidentally, everything everyone does with IPv6 always seems to be on the quiet. Did you know that Facebook’s public IP address block includes “:face:b00c:”? A legitimate hexadecimal address, to be sure, but quite literally many universes worth of grains of sand away from just taking the next available /48 off the top of the pile. I’m sure there are some Easter egg addresses in the Microsoft address allocation, too – but these offer only a glimmer of reassurance in the fog of confusion surrounding all these topics. It looks as if Microsoft can’t settle on the role it would like to occupy when it comes to roaming devices. If you had DirectAccess all set up, with the right accompanying external public DNS naming and SSL certificates, then you could get to the roaming laptop easily. It could call home to
you; so long as the link was up, you could make a connection and fix whatever it is you need to fix. This completely distinguished DA from the other “remote server control” tools, being one architecture to rule them all.
It’s rather early days to make sense of Always-on VPN in this context. It’s a replacement in Microsoft’s eyes mostly because it overcomes problems around what a company laptop should actually log into, when it’s far from home. The local network? The service provider? The LTE cell? Corporate home base? It’s a huge set of choices, each after gatekeeper responsibility. So you have to pay up before you get logged in – a nightmare for travellers and those who support them.
Microsoft’s answer is to say that the machines are always on the VPN. The structures are operational right from the instant of boot-up, with policy-delivered constraints and permissions telling the VPN connection how to wait, what to look for, who to pass through, and even how long to stay on once connected.
Some of these tricks mimic the strange experiments done to Skype over the past few years, in which certain Wi-Fi and cellular providers negotiated unpaid, unmetered pass-through arrangements so that Skype users could pay for the connection through Skype, rather then having to negotiate the strange logic and peculiar charging preferences of small-town internet connection providers (yes, GANAG of Germany, I’m thinking of you).
This old and now apparently obsolete trick required an open back-channel, so that the traveller’s machine could be sure it had credit on Skype, then wait for Skype to communicate with the back-end of the distant provider, which then pushed credentials or a “voucher” forward to your specific session. This then completed a single-purpose connection just for making that all-important evening video call at the end of a hard day.
This strikes me as an astonishing bit of overdesign, in pursuit of a usage model with as many opportunities for mischarging, ripping off and not working, as were found in the now dreadfully deprecated DirectAccess. Of the small number of people I know who are obliged to use DirectAccess by a mix of configuration and hardware vendors, I don’t know any who have made plans to move over to Always-on VPN as their daily bread remote compute connection provider. Not a good situation!
Watch out for cloud backups
My client was very puzzled. His firm had endured a bad internet week, right at the end of the hot summer. He was sure that the link speed had dropped in the preceding weeks, too, and the line behaviour looked as if it was due to poor-quality connections on the DSL side of the router. Much shrugging ensued.
No way to get BT Openreach to retest a line like that, and precious room in the surrounding wiring to ask for another route into the building. The firm’s new CEO arrived, and things got embarrassing: glitches in pictures on web pages, difficulty logging in, jittery VoIP service. Eventually, I had to go take a look.
When faced with what looks like a hopeless case, with the solution out of my reach (in this case, DSL wiring standards not being upheld), I fall back on simply mooching about. Just looking at the usual suspects to see whether any evidence pops up unexpectedly. And I got some!
This network has four VM servers on two physical hosts. It’s small. There’s a large group working remotely; they mostly want to access a database server, which isn’t terribly cutting-edge when it comes to the actual database. Nor yet are the developers, who have never been prescriptive when it comes to cloud-based backup programs, leaving final choice to the user.
On this particular day, when in mid-mooch, I jumped to the database server VM and found it laggy. In fact, testing another part of the update and talking from it to the Quad9 DNS server, I was seeing 25% packet loss. An idle look around in Task Manager and I could see there was a web page sitting minimised in the taskbar that was taking more CPU and network than the rest of the VM put together.
This was being comprehensively hidden by the dynamic load features of VMware, because these VMs are on fast, quite new servers. The web page in question was the dashboard of a new cloud-resident intelligent backup product. No current job was running. Nonetheless, just leaving the dashboard open wasn’t just eating the DSL line, it was messing up almost all the other services on the network.
Closing the page and rebooting that server as a precaution brought everything else back up to speed. Packets stopped dropping, collisions dropped away. I was flabbergasted that a mere web page could exert that much influence over an otherwise respectable network.
Okay, so it was running on a very fast machine in a clean configuration, and could therefore have produced far more mess if it had been so minded. But the simple fact remains that this devil wasn’t backing anything up at the time. It had been left idle for a few days: a situation in which most corporate cloud resources will politely log themselves out and disappear. This was doing the opposite.
The lesson is simple. You can’t have a sufficiently separated test environment in a small business. If you’re going to test at home, make sure you define a start and an end to the test process, and a recovery path if things seem to be going wrong.
“When faced with a hopeless case, with the solution out of my reach, I fall back on simply mooching about”