Veeam Community Forums Digest for dandvo [Sep 4

Veeam Community Forums Digest for dandvo [Sep 4 - Sep 10, 2017]

Veeam Community Forums Digest

September 4 - September 10, 2017

THE WORD FROM GOSTEV

I am on the way to Barcelona for VMworld Europe – and looking forward to meet many of you in person!

Last week was largely uneventful except yet another ransomware story affecting a Veeam customer (and a partner) which I simply cannot miss sharing, because no matter how similar these stories are to one another, someone can learn something new from each one – thus preventing the same disaster from happening to YOUR environment. Especially with stories like this one, which deal with hackers who are trying to be helpful so to speak (I call them Robin Hoods). These folks tend to explain the victim how they got in once the ransom has been paid – without ever being asked to do so. It is amazing how the human nature pushes most criminals to do these nice things – I am seeing this times and again, including in this particular case.

This attack has started from a Veeam backup server which was directly accessible from the Internet through RDP with a common account name "backup" and an easy to guess "password classic" – a very slight variation of the "P@ssw0rd" password (seeing one made my hair stand on end - and those who know me in person know I don't even have much). This is how the hacker got in initially. Not only did the account in question have Local Administrator privilege on the backup server, but also on the domain itself – so this particular environment was completely lost right out of gate. What is even worse, is that the backup server had saved connections to two more virtual environments belonging to the clients which this partner has been managing – obviously with admin credentials too :(

The consequences are pretty obvious – the hacker sicked a good old encrypted boot ransomware on all three environments, taking them hostage. And the partner had truly no choice but to pay thousands dollars in ransom – but in the end, was provided the decryption keys along with the breach details – just because the hacker was trying to be nice. So, what can we all learn from this particular case?

First, your backup servers should never ever be accessible from the Internet. Outbound connectivity from a backup server is usually not a problem – and is often required unless you're willing to sacrifice functionality like product update check, license auto update, licensing usage reporting of Veeam service providers and such. However, there's simply no good reason to allow inbound connectivity from the Internet to your backup servers - period. If you want to be managing your backup server remotely from the Internet, you should be doing so through a jump box with Veeam console installed, and – importantly – without saving any credentials there, and obviously with different credentials to a backup server.

Needless to say, the "no inbound connectivity" best practice still stands true even if you're a managed backup service provider who does need to connect to backup servers installed in clients' environments. Those backup servers should never allow inbound connections either – this is just waiting for the trouble to happen! Instead, as an MSP you should be using Veeam Backup Remote Access functionality, which is especially designed for this scenario. This functionality allows you to securely connect to your clients' backup servers through the existing Cloud Connect tunnel that is an outbound connection from a backup server to your (service provider's) environment.

Second, make sure the account used for RDP access does not have Local Administrator privileges on the jump box. There's simply no good reason for it to have such privileges, except if you want to help the hacker out. I explained here before how easy it is to fetch and decrypt passwords protected with the machine key from Veeam (or any other management software) if you can logon to the management server, and this is what jump box does solve. However, having Local Administrator privileges on the compromised jump box also allows a hacker to steal various LSA secrets - or even powerful domain credentials from some service account that you missed (or added later). Not to mention this also enables the installation of key loggers and advanced hacking tools - because having penetrated into your network perimeter, smart hackers always take time to collect additional information before executing the actual attack.

Third, never use saved credentials functionality for RDP or other remote console connections on your jump box – because if your access account gets compromised, you don't want the hacker to be able to immediately access other environments under some almighty credentials conveniently saved by you.

BEST POST OF THE WEEK

Re: Feature Request : Web Console [BY: rawtaz • LIKED: 5 times]

+1 for a web based API to support a HTML5 client, assuming it is done properly (but that's pretty much a given expectation, why would anyone ask for a badly designed or non-working HTML5 client).

There seems to be a lot of FUD regarding HTML5 in this thread. I'm not sure everyone in this thread understands how well a HTML5 based interface can work. Probably due to having been exposed to bad ones. Of course, it's just not HTML5 we're discussing here (also JS,CSS and the backend stuff), but for sake of brevity let's continue to use that word alone.

Regarding the VMware thing though; You cannot blame HTML5 for what VMware did. Their failure is based on two things; 1) their initial decision to replace the vSphere Client with a Flash based client (this was about the most stupid thing they could have done, and in light of what any web developer would have told them, had they just asked, it's even more silly), 2) their incompetence or lack of effort (you decide which) to make the client better during the time it's been out there.

By #2 I mean that if they just wanted to, they could fix the issues in it rather swiftly and release a client that works well and has the features people are annoyed with the lack of. They seem to be getting there, but it's not a matter of whether "HTML5" can do it, it's about VMware just getting it done. Just because they didn't do it right, doesn't mean it can't be done right.

I've been developing web based applications for more years than I can remember, and I can definitely tell you that HTML5 and related technologies is perfectly capable of providing a well designed, highly usable and user friendly interface even for Veeam stuff. It's just about doing it right. If there's a problem here, it's not the technology.

Regarding the development of it, sure, there's sometimes a lot of headaches due to this and that browser (they all have their pros and cons), but in general HTML5 has been around for so long now, that all or most of the things you need to build this type of client is there and supported by the browsers that are relevant for this discussion. It's possible the effort needed to produce this client compared to one that is more platform specific is greater though, as there are more parts involved to get right.

Someone mentioned CPU load, but this isn't really rocket science - the frontend we're talking about here isn't going to do a ton of processing. None of what it needs to do is CPU intensive enough to be a problem AFAIK. And sure, there can in some cases be a bit of network delays, but as long as you're not on a slow connection it should just be fine. Just think about how much actual data needs to be transported to your UI, in the cases where there's the most going on in the current client - not very much at all.

One thing I would appreciate is if we could get to a point where we don't need Windows systems just to run Veeam. But that's probably a bit far away, since even if we get a web GUI, there's still the actual backup controller, proxy, etc that has to be run on Windows. So from that perspective, my personal use case for a HTML5 client is rather limited. What I need to do I can do in a Windows client, since I have to have Windows set up for Veeam anyway :/

If there's a HTML5 client created, then heck yes, it definitely should be working through an API that other people can build stuff around if they want! That's one of the pros with this type of solution. So perhaps, as some people here seemed to suggest, the best way forward into HTML5 land is to simply provide that API, so the community might start writing som stuff around it, showing the way to what might later become a design and feature set in the final client.

Also, make the things open source so people can contribute.

ddprecist

Prohledat tento blog

Veeam Community Forums Digest for dandvo [Sep 4 - Sep 10, 2017]

Komentáře

Okomentovat