CDP DNS Dependency

[mog54]

Hello,

I'm concerned about this dns dependency.
Is that mean in a ransomware attack, where AD/DNS is corrupted, the inability to start the replicas trough veeam because of the dns not working ?

Or the DNS is juste mendatory for the I/O filter deployement

Thank You
Have a nice day

[Gostev]

That thread was about CDP I/O filter installation, and specifically the VMware VIB deployment framework and its hardcore DNS dependency.

But as a short comment, it's hard for me to see how any functionality at all (not just CDP) can work when no network connections can be established, because IP addresses of remote servers cannot be resolved. For example, this would mean Veeam backup server will not be able to connect to a vCenter server => even most basic VM restores are not possible! DNS servers are the most critical part of the infrastructure, which is why they are typically made redundant.

[mog54]

That's why since v7.0 of vcenter i didn't use FQDN wich was mandatory in v6.X and only use ip (for esx too).
That's not "sexy" but it's not dependant of DNS/AD wich is the first thing comprimised in ransomware attacks

Thank you for your answer

[Gostev]

If you are truly worried about the environment being compromised, then I am not sure if using IP addresses is a good idea in the bigger picture, because Kerberos (you mentioned AD) requires FQDN usage. Or do you just assume you will be compromised anyhow, and thus are even ready to make it easier for hackers, in order to simplify recovery for yourself? Because most customers rather focus on making it harder for attackers to take over the environment...

Also, I don't know why DNS would be the first thing compromised in ransomware attacks. May be that's the issue you should solve. Standalone DNS server seems to be some of the easiest workloads to secure by just closing all ports except 53, no? Management would require local/physical console access, but how often do you need to do this to a DNS server? And good luck to ransomware and even hackers in taking it over with only port 53 open... I've seen some firewalled Linux-based DNS servers running for over a decade unpatched!

[Andreas Neufert]

There is a very simple workaround. You can add all Veeam and VMware Server to the local hosts file of the Veeam Server, VMwareESXi Server and the vCenter.
That way DNS is working and continue when DNS is down.

vCenter APIs work with the FQDN of the ESXi host even if you have added the ESXi hosts by IP addresses.

[mog54]

If you are truly worried about the environment being compromised, then I am not sure if using IP addresses is a good idea in the bigger picture, because Kerberos (you mentioned AD) requires FQDN usage. Or do you just assume you will be compromised anyhow, and thus are even ready to make it easier for hackers, in order to simplify recovery for yourself? Because most customers rather focus on making it harder for attackers to take over the environment...

Hello,

I guess i got my mind in this way, after spending many hours helping customers to recover of ransomware attack

I understand that you have to make hard to take over the environment, but imo, working on the case of "attacker are in the network" is important too.

Also, I don't know why DNS would be the first thing compromised in ransomware attacks.

For deploying the ransomware they need to grant access to admin account, so you can't trust active directory anymore, and since DNS is on the same server you can loose the DNS service for a while.

May be that's the issue you should solve. Standalone DNS server seems to be some of the easiest workloads to secure by just closing all ports except 53, no? Management would require local/physical console access, but how often do you need to do this to a DNS server? And good luck to ransomware and even hackers in taking it over with only port 53 open... I've seen some firewalled Linux-based DNS servers running for over a decade unpatched!

Yeah a standalone DNS can be the workaround, i keep this idea in my mind for the future.

vCenter APIs work with the FQDN of the ESXi host even if you have added the ESXi hosts by IP addresses.

Do you mean for CDP or globally ? Because i use veeam with vcenter/esxi without fqdn and dns entry and there is no issues.

Thank you both for your answer !
Have a nice day

[Andreas Neufert]

All VMware APIs including VAIO used for Veeam CDP and APIs used for the normal VMware backup processing depend on correct working FQDN so that signatures, certificates, SSO and other things work correctly. We implemented a lot of code in our standard VMware processing that can fallback to the IP addresse processing as workaround. But for CDP it is hard coded in the VMware internal part and therefore DNS need to work.

Just to give you an idea. When you want to follow the security guidlines correctly the vcenter and hosts should have trusted certificates and you should not have to accept non trusted certificates when you add the vcenter to Veeam. So you could even argue that the non DNS environment is less secure.

[mog54]

Ok i take note of that !

Just to give you an idea. When you want to follow the security guidlines correctly the vcenter and hosts should have trusted certificates and you should not have to accept non trusted certificates when you add the vcenter to Veeam. So you could even argue that the non DNS environment is less secure.

I understand, but if i ask you how many veeam customer is using trusted certificate (internal or external) on their vmware infrastructure vs the overall number of veeam customers i would bet the ratio is very small. Correct me if i am wrong !

Of course non dns environement is less secure overall but on other side i think that your virtualization/backup infrastructure rely on the highest osi layer to working properly make me feel uncomfortable. Like hyperv cluster need active directory/dns do start.

Thanks you

[Andreas Neufert]

Yes, I think the number is small. But there is a growing customer base where they enforce this to be compliant with their security audits.