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 Manual.
In SSH sessions it is possible to identify user-typed commands that are to be executed on the target 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.
Let's understand which type of actions a command can trigger, how sessions are affected by these actions, and what the difference of a session with and without audited commands is.
SSH sessions with and without audited commands
Sessions that do not have audited commands will start directly to the target device in the same way that the user connects to the device without using senhasegura . Hence, the terminal configured in the target user's account will be allocated to a session TTY, and all key combinations typed will be immediately forwarded to the target device.
When audited commands are configured we must be careful that the commands typed in the terminal are evaluated before allowing execution. This would be much more complex acting directly on the natural terminal of the remote device. And it would be much more intrusive if there was a need to install agents on all target devices.
In this scenario, 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 routed to the remote device.
But if the client 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.
Like other proxy session settings, 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.
A command can be changed as long as it has not been linked to a proxy session. But it can be inactivated.
Within the editing form you have the Urgency and Score field to determine the score in User Behavior.
The Occurrences and Block user fields determine whether the user will have their senhasegura account blocked.
The Action during session field are the primary actions that will be taken.
The Command field is the regular expression that will be applied to the command that is 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.
Let's now look at how a command reacts when it is framed to a rule.
The Global command below allows you to execute commands that contain some mapped binaries.
Note that when executed, commands run normally. But first they will be registered in senhasegura .
Now we will see a rule that denies executing commands. The rule below denies executing commands that interfere with services on some devices.
Note that when run on a related device, the command will stop and the attempt will be logged.
allowlist commands behave similarly but there is no notification if something outside the allowlist is blocked.
In cases of 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 bring a view of how users are operating the systems.
This helps the administrator understand whether procedures need to be adjusted, whether users require training, and whether credentials and devices are at risk.
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 involved through the Threat radar Dashboard. Accessible at the Dashboard ➔ PAM ➔ Radar ➔ Threat radar Dashboard menu.
This radar displays the sessions running and that have some audited command 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.
The radar shows several colored dots. Hot colors present sessions that have had risk commands executed. And the cool colors have no risk commands.
By clicking the point, you have details of the sessions that occurred at that time. And when you click the session log action, it will display a card with the session details.
The axes of this radar always show the interval applied in the filter divided into four quadrants. The proximity of the epicenter, flag that the session occurred near the full hour, and the proximity of the peripheral area, flag that the session occurred in the last minutes of the hour.
The placement in the wind rose flag the date (or time) when the command occurred.
Note the example image that the commands were almost all executed in 11-day sessions between 0 and 4 hours.
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 most risky accesses and who are the most affected users and devices.