Jump to content

DarrenWhite99

Administrator
  • Content Count

    1238
  • Joined

  • Last visited

  • Days Won

    175

DarrenWhite99 last won the day on July 2

DarrenWhite99 had the most liked content!

Community Reputation

423 Excellent

My Information

  • Location
    Redding, California, US
  • Agent Count
    2000 - 3000 Agents

Converted

  • OCCUPATION
    Senior Systems Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Version 1.3.1

    10 downloads

    This script is intended to be used as a function script, but is flexible and can be ran manually. The script generates a random InstallerToken value for the location and installer type requested, valid for a variable length of time. These can be used to create installer download links valid for more than 24 hours that can be given to clients, or used in deployment scripts. They can also be issued for shorter periods specifically for on-demand agent installation (such as reinstalling an Automate agent through Control). The expected use case is for scripted creation of batch (or powershell) agent deployment scripts that download the agent installer at run time. Another script can call this one to generate a token, and then write that token into the deployment script. This is an improvement over deployment solutions that require the server password to be stored as the installertoken can expire or be selectively revoked at any time with very little impact, but a server password reset impacts all installers for all clients.
  2. View File Generate Agent InstallerToken This script is intended to be used as a function script, but is flexible and can be ran manually. The script generates a random InstallerToken value for the location and installer type requested, valid for a variable length of time. These can be used to create installer download links valid for more than 24 hours that can be given to clients, or used in deployment scripts. They can also be issued for shorter periods specifically for on-demand agent installation (such as reinstalling an Automate agent through Control). The expected use case is for scripted creation of batch (or powershell) agent deployment scripts that download the agent installer at run time. Another script can call this one to generate a token, and then write that token into the deployment script. This is an improvement over deployment solutions that require the server password to be stored as the installertoken can expire or be selectively revoked at any time with very little impact, but a server password reset impacts all installers for all clients. Submitter DarrenWhite99 Submitted 06/30/20 Category Scripts  
  3. First, some basics of vulnerability classes and severity of risk. Any connection to your server from a host other than the server is a remote connection. A request from the server is local. Any request to retrieve or to submit information may include some token identifying the session. A session without any identifying token/secret is unauthenticated. A session with a valid secret is authenticated. Different URLs/endpoints/services/etc. on the server accept different types of requests, different types of authentication, and may impose different restrictions based on the identity of the session. These are based on privileges or permissions. The classes of vulnerabilities from greatest risk to least are ones that can be exploited by an attacker that is: Remote, Unauthenticated Remote, Authenticated, Unprivileged Remote, Authenticated, Privileged Local, Unauthenticated Local, Authenticated, Unprivileged Local, Authenticated, Privileged Agents are authenticated by their unique ID plus a unique (per-agent) password. A "compromised" agent is an agent whose unique password is known by a third party. Having this password means that requests to the server are AUTHENTICATED Remote connections. Agents are low privilege, only able to update or request information associated with themselves. The recently discovered vulnerabilities were exploitable by a remote authenticated attacker, authenticating as an agent (using the agent's password). To obtain an agent password an attacker must register as an agent, which requires the server password. The ability for an unauthenticated remote user to obtain the server password is what made the exploit be considered to be vulnerable to an unauthenticated attacker. This is why the first response was denying access to the server password so that the risk was limited to only existing agents. Then the patches resolved the discovered vulnerabilities based on having an agent password. So, case closed? No more worries? Well.... The patches resolved these KNOWN vulnerabilities. These vulnerabilities were not "inherent", as in the security was not based on the agent being trusted to "behave". But programming mistakes still allowed a misbehaving agent to trick the server. The nature of a complex product is that there may be other undiscovered flaws. If a user's password was compromised, wouldn't you require the password to be reset? Removing nonfunctional agents is the same thing, a precaution to insure that if that agent's password has been compromised we are "resetting" it so that it can no longer be used. I hope this clears up what the general risks are to having a compromised agent password. Directly answering your 4 questions: The system password is included in every installer bundle, so anyone able to obtain an installer package has access to the server password. Until you change it, anyone that may have collected it in the past can make use of it in the future. The risks of an attacker having the system password are simply that they can move from unauthenticated attacks to authenticated attacks, as they are able to establish a password and authenticate as an unprivileged agent user. The risks of a compromised agent password are simply that if other vulnerabilities exist that can be exploited by an unprivileged agent, an attacker already has valid credentials. As long as the server password permits an agent to register (probably not changing unless the entire process is changed) it's reasonable to consider periodic rotation to become considered a best practice to increase security. (My own opinion) The bottom line: Regardless of whether or not you consider Automate to be an "inherently" insecure platform as long as a compromised agent is present, a server is inherently more vulnerable to a potential future attack.
  4. I still have the regular hourly Onboarding scripts scheduled. This just kicks things off quicker. The onboarding script can safely run repeatedly until the "Onboarding Complete" EDF gets set.
  5. That's fine when the location supposed to be trusted but is not being detected correctly. The original command was specifically for when a machine was introduced to a new location (which it would not trust) and we wanted to define this as "trusted". A common situation is for BDR/Appliance servers that are dropped onsite. We would image them inhouse but not complete any onboarding steps in Automate. Once delivered and connected we assigned the agent to the correct client/location and ran an onboarding script that included setting the current (client) network as trusted.
  6. The monitor automatically sets the threshold for you. But result is the level of free licenses you want to be warned at. You need to make sure the alert template is valid. If you want a ticket, use a template that generates a ticket. To send email, use a template that sends an email. Etc.
  7. Fix heartbeat: https://gavsto.com/agent-response-slow-tired-of-waiting-to-interact-with-agents-offline-server-alerts-flaky-your-heartbeat-may-be-broken/ Enable Fasttalk in the script when it starts.
  8. Try \/[a-z]* ? But actually it’s best if you can post a sample of the output you are working with.
  9. Yes, it is in the database. I was commenting on the agent not sending that as a distinct value, but rather simply reporting who IS logged in and the server copies to the “lastuser” column. (There is a column for current logged in users, and one for the last logged in user. The agent updates the first column, the server updates the second)
  10. I don’t think the agent sends a “last user”. I believe it reports the logged in users, and each time it changes the database agent copies a name to that column. Logged In users are reported (at least) during each check- in, which is every 5 minutes normally. (Or every 30 seconds for probes or masters?)
  11. Umm.... Maybe it’s because I didn’t re-read the whole topic, but what problem are you asking about?
  12. That’s the problem. You could try replacing the TO_BAS64/FROM_BASE64 calls with BASE64_ENCODE/BASE64_DECODE. Those are stored procedures available in Automate, but they aren’t as fast as the native functions I’m using in 5.6+.
×
×
  • Create New...