I'm trying to set up a scheduled task that runs some SSH commands on a device, but it requires a password, and I'm concerned about security. I've been exploring options, but I'm looking for advice on how to run this task safely. I know you typically encrypt the password, either through built-in options or third-party secret management tools, but I have my doubts about whether that's enough. Here are some considerations:
- I shouldn't run this task as SYSTEM because any admin, including potentially compromised ones, could access and decrypt the password.
- Scripts can be edited or replaced, even signed ones, to expose sensitive information like passwords.
- I'm considering base64-encoding the whole script to include it as an argument, but I'm worried about argument length limitations in scheduled tasks and I still need the service account password to update it.
It would be great if powershell.exe could check a file's hash before executing it, but I recognize that I need the service password to alter the scheduled task. Using '-ExecutionPolicy RemoteSigned' doesn't seem reliable since a malicious script can still be signed with a valid certificate. Any advice on best practices for securing this kind of scheduled task?
5 Answers
Quick note — base64 encoding is not actually encryption! It's easily reversible, so it won’t provide the security you're looking for. Just something to keep in mind while you're working on this!
There are definitely multiple layers you can add to this process. Start by restricting access to the server itself; if you can keep unauthorized users out, modifying scripts becomes trickier. Use the Secret Management Module so your script doesn't contain hardcoded passwords. Also, enforce signing of scripts and manage trusted certs through Group Policy. Make sure your scripts are stored securely with the right permissions so that only your gMSA has read access. This way, you'd minimize risks while keeping your server as secure as possible.
I appreciate that! We already restrict server access. Managing the Trusted Publishers is a new angle I hadn’t considered.
You're already touching on some crucial points. If you want to protect the script from admins, you might be out of luck, since they hold a lot of power when it comes to system access. That said, if your goal is just to shield it from non-admin users, you can consider signing your scripts and utilizing a Group Managed Service Account (gMSA) for running the task. This way, you avoid storing the password directly in the script. You can also use the -CmsMessage cmdlet to encrypt the password with a certificate so only your gMSA can decode it.
Got it! So if I use 'AllSigned' as the Execution Policy, it'll only run if the signing certificate is trusted. That’s helpful to know!
Have you considered using a system-managed identity for the task? You could then set up certificate-based authentication for SSH, which might be another way to securely handle this without needing to worry about the password in the script.
Encrypting files as you suggested might raise alarms with your SIEM since it resembles malware behavior. The standard practice includes changing file permissions, running scripts via a managed service account, and auditing files for changes. It’s important to remember that security isn't about being completely impenetrable; it's about minimizing damage. Implementing effective change auditing can help keep track of any modifications.
Absolutely, limiting access while also tracking changes makes a lot of sense. I'll look into file change auditing.
Thanks for the clarification! I had the wrong idea about that.