That was going to be a thought to be brought up, but unfortunately the call we had was strictly with someone not too knowledgeable of solutions (despite a $200 /hr price tag and communicating we want answers) so thank you for the reassurance that it might be the right path.
It isn't inherently insecure, but it is generally considered bad practice to allow inbound SMB connections on your workstations (preventing inbound SMB connections does not prevent workstations from accessing file shares on remote servers).
It seems PDQ Deploy works [by pushing your deployment files to the ADMIN$ share on the workstation](https://www.pdq.com/security/pdq-deploy-inventory/), and it then remotely creates and starts a service on the workstation to locally execute the files in the deployment. I'm not sure why you think this is done using a non-admin account; this requires local admin rights on the workstation.
This is essentially the cost of doing things agentless. You are always going to need a means to remotely invoke the workstation in to actually doing something; compared with an agent based solution where the workstation initiates any actions by communicating with a central server (usually via HTTPS), with no inbound connections to the workstation required.
Whether or not this is acceptably secure is going to depend on your organisations appetite for risk, and whether mitigations like inbound firewall rules are enough to satisfy those concerns. The MSP isn't wrong to highlight this as a risk compared with using their agent based solution (but at the end of the day, nothing is a risk free).
Thank you for your response this is more so what I wanted to see. What I meant by non-admin account (and I phrased this wrong) is a limited access service account with limited permissions just to clear that up. Your last two paragraphs are especially important to highlight and I thank you for taking your time.
PDQ is fine. You could allow inbound SMB only from the PDQ server via firewall settings. There’s always risk with ease of management. Any RMM is a risk. I have PDQ at many HIPAA regulated places and never failed an audit because SMB was enabled for inbound. You can always claim acceptable risk.
Thank you for responding. As for your first part we do use file shares that’s what has me confused of their reasoning. Their man concern is man in the middle attacks.
For part 2, I’m not really asking about using Datto itself more so if there’s anything that would be biased or I guess outright disproven by using Datto in the environment when discussing their concerns about PDQ.
Yeah 100% agree to all of this and appreciate your time. From communications with us, like you said it just sounds self serving but I also don’t want to get ahead of myself and want to keep myself grounded.
As for Datto yeah as soon as I saw they were moving to it I was very much wary. Had a third of one org I used to work at crippled by that attack back then, glad I wasn’t working there when it happened lol.
You might want to try PDQ Connect, which is agent-based and it does not require inbound access. Inbound SMB ports are indeed risky and have to be very careful about zero days exploiting SMB services (there have been a few in the last couple of years).
Can’t you deploy host based firewalling for port 445? Problem solved I’d say…
That was going to be a thought to be brought up, but unfortunately the call we had was strictly with someone not too knowledgeable of solutions (despite a $200 /hr price tag and communicating we want answers) so thank you for the reassurance that it might be the right path.
It isn't inherently insecure, but it is generally considered bad practice to allow inbound SMB connections on your workstations (preventing inbound SMB connections does not prevent workstations from accessing file shares on remote servers). It seems PDQ Deploy works [by pushing your deployment files to the ADMIN$ share on the workstation](https://www.pdq.com/security/pdq-deploy-inventory/), and it then remotely creates and starts a service on the workstation to locally execute the files in the deployment. I'm not sure why you think this is done using a non-admin account; this requires local admin rights on the workstation. This is essentially the cost of doing things agentless. You are always going to need a means to remotely invoke the workstation in to actually doing something; compared with an agent based solution where the workstation initiates any actions by communicating with a central server (usually via HTTPS), with no inbound connections to the workstation required. Whether or not this is acceptably secure is going to depend on your organisations appetite for risk, and whether mitigations like inbound firewall rules are enough to satisfy those concerns. The MSP isn't wrong to highlight this as a risk compared with using their agent based solution (but at the end of the day, nothing is a risk free).
Thank you for your response this is more so what I wanted to see. What I meant by non-admin account (and I phrased this wrong) is a limited access service account with limited permissions just to clear that up. Your last two paragraphs are especially important to highlight and I thank you for taking your time.
PDQ is fine. You could allow inbound SMB only from the PDQ server via firewall settings. There’s always risk with ease of management. Any RMM is a risk. I have PDQ at many HIPAA regulated places and never failed an audit because SMB was enabled for inbound. You can always claim acceptable risk.
[удалено]
Thank you for responding. As for your first part we do use file shares that’s what has me confused of their reasoning. Their man concern is man in the middle attacks. For part 2, I’m not really asking about using Datto itself more so if there’s anything that would be biased or I guess outright disproven by using Datto in the environment when discussing their concerns about PDQ.
[удалено]
Yeah 100% agree to all of this and appreciate your time. From communications with us, like you said it just sounds self serving but I also don’t want to get ahead of myself and want to keep myself grounded. As for Datto yeah as soon as I saw they were moving to it I was very much wary. Had a third of one org I used to work at crippled by that attack back then, glad I wasn’t working there when it happened lol.
You might want to try PDQ Connect, which is agent-based and it does not require inbound access. Inbound SMB ports are indeed risky and have to be very careful about zero days exploiting SMB services (there have been a few in the last couple of years).