Audited commands
The command filter functionality is not available for RDP Proxy for security reasons. To use it check our content about RDP command filtering for PowerShell and CMD in the senhasegura.go.
senhasegura offers an intermediate terminal that runs internally on SSH proxy technologies. This intermediate terminal evaluates the command at run time and determines based on the active rules whether or not it can be executed to the remote device.
These commands can be evaluated using regular expression patterns defined by the administrator himself, and if they fit the pattern, an action can be taken.
In this way, you can create several types of settings that allow or inhibit the execution of certain commands. But it is necessary that the person configuring the commands have a good knowledge of regular expressions in order for the commands to be evaluated correctly.
if the user has started a binary on the target server, this binary will then be delivered to the user operator control. And in this case, the audited commands are no longer evaluated. This allows there no conflict between terminal commands and texts and arguments used in other binaries.
Actions triggered by execution of audited commands
When an audited command rule is applicable to a command line that the operator user wants to execute, senhasegura will record the time of the proxy session when it happended, and sum the score of the risk of this executed command into the session. This notification will also be sent under SIEM.
Additionally, the rules defined by the administrator will be applied. There are four direct actions and one indirect action that can be performed.
Allow execution: Execution will be allowed;
Deny execution: The operator user will be prevented from executing the command. These commands are considered a deny-list;
Interrupt session: The operator user will be prevented from executing the command and will have the proxy session interrupted. These commands are considered a deny-list;
Force: The user will only be able to execute the commands allowed by these rules. These commands are considered a mandatory-list;
The rules will be summed up. This means that the administrator can record as many rules as he finds convenient. But when the session starts, senhasegura will initially validate the rules considered mandatory-list, later the deny-list rules, and finally the registration rules. If the command is applicable in one of the evaluated rules, the check chain is terminated.
The mandatory-list rules end up completely overlapping the others, since they will always apply.
Rules will always be evaluated within your groups. If there is more than one mandatory-list rule applicable to the session, both are evaluated. Therefore the command may not be allowed by a first rule, but can be valid by the second rule. The command would only be denied if no mandatory-list rule allows the command.
These deny-list and mandatory-list rules are the direct actions. There are also indirect actions that can be configured.
Lock senhasegura account: If the rule is applicable, regardless of type, the user's access account can be locked after a number of repetitions of the command;
User Behavior Score: The command can receive three types of scores that will feed the user, device, and credential behavioral statistics;
Registering new commands
Through the PAM ➔ Settings ➔ Access ➔ Audited commands you have access to the report where all applicable commands are related.
Audited commands allow segregations at the Global, Access Group, Device, and Credential level.
The difference is that there will be no overlap of a command based on the chain of segregating entities. It's a sum of rules.
See this segregation as a possibility to isolate commands pertaining to certain credentials and devices from a particular manufacturer.
Command Tab
A command can be changed if it has not been linked to a proxy session.
Within the editing form, you have the Urgency and Score fields to determine the score in User Behavior.
The Occurrences and Block user fields determine whether users will have their senhasegura account blocked.
The Action during session field are the immediate actions that senhasegura will take.
The Command field is the regular expression that will be applied to the command to be executed.
If you need to create a command similar to a command that already exists, including entities that are already linked (such as device, credential, or access group), you use the Clone command footer action in the editing form of an existing command.
Allows execute command
The Global command below allows you to execute commands that contain some mapped binaries.
When executed, commands run normally. But first they will be loged in senhasegura behavior reports.
Deny execute command
The rule below denies executing commands that interfere with services on some devices.
The command will stop and log the attempt when running on a connected device.
Allowlist commands behave similarly, but there is no notification if something outside the allowlist is blocked.
In cases of a session interruption, there is an additional step for the compulsory session logout.
Logs and Command Executions
As soon as commands are matched to an audited command rule, both the session and the rule are now linked.
Through the audited commands report you can observe every time the rule has been applied through the View audit history record action.
Session logs also display the details of this run detailing which audited command is matched, its score applied, and the time of execution.
Session logs can be accessed in the PAM ➔ Access control ➔ Remote session report.
Audited commands and User behaviour
The User behavior module will link various information related to resource usage in senhasegura. But for the audited commands, we have special screens that show how users are operating the systems.
Through the Behavior ➔ Occurrences report, you will have access to reports that deliver a view of which Devices, Credentials, and Users are outside the scheduled usage curve.
You can get a graphical view of the risky command executions through the Threat radar Dashboard. Accessible at the Dashboard ➔ PAM ➔ Radar ➔ Threat radar Dashboard menu.
This radar displays the sessions running that have some audited commands registered. If you click the History button, located in the upper right corner of the dashboard, you have access to the execution history of the last four days. You can change the period through the top filter of the dashboard, but let's explain the radar.
By clicking the point, you have details of the sessions that occurred. And when you click the session log action, it will display a card with the session details.
Through the Dashboard ➔ PAM ➔ Commands menu, you have access to a dashboard dedicated to commands.
The commands will also be presented in a general ranking that allows you to map the riskiest accesses and who are the most affected users and devices.