Inscreva-se no feed

It can be a challenging and time-consuming process to determine the root cause of a security incident. Because of this, Red Hat introduced the ability to record terminal sessions in Red Hat Enterprise Linux (RHEL) 8. 

This functionality, called session recordings, allows you to audit what users have done from the terminal. Recordings can be easily viewed from the command line or from the web console, and not only can you increase their playback speed, but also search for keywords and jump easily to relevant portions of the recording. 

The session recording functionality is provided by the tlog package.  

If you would like to implement session recording across your environment, you can either implement it manually or use the tlog RHEL System Role to automate its installation and configuration across your RHEL environment.  

RHEL System Roles are a collection of Ansible roles and modules that are included in RHEL to help provide consistent workflows and streamline the execution of manual tasks. If you aren’t already familiar with session recording, please refer to the RHEL documentation on using the session recording solution in Red Hat Enterprise Linux 8

Environment overview

In my example environment, I have a control node system named controlnode running RHEL 8 and three managed nodes: rhel8-server1, rhel8-server2, and rhel8-server3, all of which are also running RHEL 8.  

Note that session recording is a RHEL 8 feature, so the tlog System Role does not support RHEL 7 or older systems. The recommended method of implementing session recording is via the System Security Services Daemon (SSSD), which is the method that will be used in the examples below.  

Figure 1.

There are several options for determining which user’s terminal sessions are recorded:

  • Record terminal sessions for all users

  • Record terminal sessions for all users, except for a list of users and groups that should be excluded from recording

  • Record terminal sessions for only a specified list of users or groups. 

In this post, I’ll demonstrate all three methods. On the three managed nodes (rhel8-server1, rhel8-server2, and rhel8-server3), I have the following groups and users:

  • wheel group, with users:

    • adminuser1

    • adminuser2

  • itoperations group, with users:

    • operationsuser1

    • operationsuser2

  • customer1 user account without any unique group memberships

  My desired configuration that I would like the tlog RHEL System Role to implement is:

  • Terminal sessions should be recorded for all users on rhel8-server1

  • On rhel8-server2, all users should be recorded with the exception of:

    • Any user account that is a member of the itoperations group should not be recorded

    • The customer1 user account should not be recorded

  • On rhel8-server3, only the specified group and user should be recorded:

    • Any user account that is a member of the wheel group should be recorded

    • The customer1 user account should be recorded

I’ve already set up an Ansible service account on the four servers, named ansible, and have SSH key authentication set up so that the ansible account on controlnode can log in to each of the systems.

In addition, the ansible service account has been configured with access to the root account via sudo on each host. I’ve also installed the rhel-system-roles and ansible packages on controlnode. For more information on these tasks, refer to the Introduction to RHEL System Roles post. 

In this environment, I’m using a RHEL 8 control node, but you can also use Ansible Tower as your RHEL system role control node. Ansible Tower provides many advanced automation features and capabilities that are not available when using a RHEL control node. For more information on Ansible Tower and its functionality, refer to this overview page

Defining the inventory file and role variables

I need to define an Ansible inventory to list and group the hosts that I want the tlog System Role to configure.  

From the controlnode system, the first step is to create a new directory structure:

[ansible@controlnode ~]$ mkdir -p tlog/group_vars

These directories will be used as follows:

  • tlog directory will contain the playbook and the inventory file.

  • tlog/group_vars will define Ansible group variables that will apply to the groups of hosts that were defined in the inventory file.

I’ll create the main inventory file at tlog/inventory.yml with the following content:

all:
  children:
    record_all:
      hosts:
        rhel8-server1:
    record_all_except:
      hosts:
        rhel8-server2:
    record_only_some:
      hosts:
        rhel8-server3:

This inventory lists the three hosts, and groups them into three groups:

  • record_all group contains the rhel8-server1 host.

  • record_all_except group contains the rhel8-server2 host

  • record_only_some group contains the rhel8-server3 host

 

If using Ansible Tower as your control node, this Inventory can be imported into Red Hat Ansible Automation Platform via an SCM project (example Github or Gitlab) or using the awx-manage Utility as specified in the documentation.

Next, I’ll define the role variables that will control the behavior of the tlog System Role when it runs. The README.md file for the role, available at /usr/share/doc/rhel-system-roles/tlog/README.md, contains important information about the role, including a list of available role variables and how to use them. 

I’ll be using the following variables to achieve my desired session recording configuration:

  • tlog_scope_sssd: Specifies if the SSSD recording scope to be set to all, some, or none.

  • tlog_users_sssd: List of users that will be recorded.

  • tlog_groups_sssd: List of groups.  For each group, user accounts that are a member of the group will be recorded.  

  • tlog_exclude_users_sssd: List of users that should be excluded from being recorded (applicable when tlog_scope_sssd is set to all).

  • tlog_exclude_groups_sssd: List of groups,  For each group, user accounts that a member of the group will be excluded from being recorded (applicable when tlog_scope_sssd is set to all).

Next, I’ll create a file that will define variables for the system (rhel8-server1) listed in the record_all Ansible inventory inventory group by creating a file at tlog/group_vars/record_all.yml with the following content:

tlog_scope_sssd: all

The tlog_scope_sssd variable is set to all, which will cause all accounts to be recorded on the system.  

I’ll create the tlog/group_vars/record_all_except.yml file to define the variables for the system (rhel8-server2) listed in the record_all_except Ansible inventory group with the following content:

tlog_scope_sssd: all
tlog_exclude_users_sssd: 
  - customer1
tlog_exclude_groups_sssd: 
  - itoperations

The tlog_scope_sssd is again set to all, however I also utilize the previously discussed tlog_exclude_users_sssd and tlog_exclude_groups_sssd to exclude the specified user and group.

I’ll create the final group_vars file at tlog/group_vars/record_only_some.yml to define the variables for the system (rhel8-server3) listed in the record_only_some Ansible inventory group, with the following content:

tlog_scope_sssd: some
tlog_users_sssd: 
  - customer1
tlog_groups_sssd: 
  - wheel

This time, I set tlog_scope_sssd to some, and then utilized the previously discussed tlog_users_sssd and tlog_groups_sssd variables to list out the user and group that should be recorded. With this configuration, only the user and group I specified will have their sessions recorded.  

Creating the playbook

The next step is creating the playbook file at tlog/tlog.yml with the following content:

- name: Run tlog System Role
  hosts: all
  roles:
    - redhat.rhel_system_roles.tlog

This playbook simply calls the tlog RHEL System Role for all of the systems defined in the inventory file.    

If you are using Ansible Tower as your control node, you can import this Ansible playbook into Red Hat Ansible Automation Platform by creating a Project, following the documentation provided here. It is very common to use Git repos to store Ansible playbooks. Ansible Automation Platform stores automation in units called Jobs which contain the playbook, credentials and inventory. Create a Job Template following the documentation here

Running the playbook

At this point, everything is in place, and I’m ready to run the playbook. If you are using Ansible Tower as your control node, you can launch the job from the Tower Web interface. For this demonstration, I’m using a RHEL control node and will run the playbook from the command line. I’ll use the cd command to move into the tlog directory, and then use the ansible-playbook command to run the playbook. 

[ansible@controlnode ~]$ cd tlog
[ansible@controlnode tlog]$ ansible-playbook tlog.yml -b -i inventory.yml 

I specify that the tlog.yml playbook should be run, that it should escalate to root (the -b flag), and that the inventory.yml file should be used as my Ansible inventory (the -i flag). 

After the playbook completes, I verified that there were no failed tasks:

Figure 2.

Validating the configuration

To validate my desired configuration for session recording was properly set up, I can ask that the five users log in to the system, and validate that the proper recordings are present, or not present, based on my desired configuration, which was:

  • Terminal sessions should be recorded for all users on rhel8-server1.

  • On rhel8-server2, all users should be recorded with the exception of:

    • Any user account that is a member of the itoperations group should not be recorded (the operationsuser1 and operationsuser2 users are members of the group).

    • The customer1 user account should not be recorded.

  • On rhel8-server3, only this specified group and user should be recorded:

    • Any user account that is a member of the wheel group should be recorded (the adminuser1 and adminuser2 users are members of the group).

    • The customer1 user account should be recorded.

On rhel8-server1, all five users (adminuser1, adminuser2, operationsuser2, operationsuser1, and customer1) log in, and each of them receives a notification that their session is being recorded, which matches the desired configuration. I can also validate that I can view the recordings in the Web Console on rhel8-server1 for each of these users:

Figure 3.

On rhel8-server2, all five users (adminuser1, adminuser2, operationsuser2, operationsuser1, and customer1) log in, and only the sessions for the adminuser1 and adminuser2 account are recorded, which matches the desired configuration for this host.  

And again on rhel8-server3, all five users (adminuser1, adminuser2, operationsuser2, operationsuser1, and customer1) log in, and only the sessions for the adminuser1, adminuser2, and customer1 accounts are recorded, which again matches my desired configuration for this host.  

Conclusion

The tlog System Role can help you quickly and easily implement session recording across your RHEL environment, increasing your ability to determine root cause analysis when things go wrong by improving your ability to audit what has occurred on your systems.  

In this post, we demonstrated a number of different methods to specify which users and groups should be recorded on the system: recording all users, recording all users except specified users and groups, and only recording the listed users and groups.

We offer many RHEL System Roles that can help automate other important aspects of your RHEL environment. To explore additional roles, review the list of available RHEL System Roles and start managing your RHEL servers in a more efficient, consistent and automated manner today. 

Want to learn more about Red Hat Ansible Automation Platform? Check out our e-book, "The automated enterprise: Unify people and processes." 

.boxed { border: 1px solid black ; } table { border: #ddd solid 1px; } td, th { padding: 8px; border: #ddd solid 1px; } td p { font-size: 15px !important; }


Sobre o autor

Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management.  He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).  

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Navegue por canal

automation icon

Automação

Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes

AI icon

Inteligência artificial

Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente

open hybrid cloud icon

Nuvem híbrida aberta

Veja como construímos um futuro mais flexível com a nuvem híbrida

security icon

Segurança

Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias

edge icon

Edge computing

Saiba quais são as atualizações nas plataformas que simplificam as operações na borda

Infrastructure icon

Infraestrutura

Saiba o que há de mais recente na plataforma Linux empresarial líder mundial

application development icon

Aplicações

Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações

Original series icon

Programas originais

Veja as histórias divertidas de criadores e líderes em tecnologia empresarial