You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tlog cannot be used to record superuser sessions securely. For those sessions
another approach should be used, such as jump server. In a jump-server setup
the user first logs in to a machine which records all the terminal I/O, and
then from that machine he/she logs in to the target machine.
This allows recording terminal I/O securely. Still, audit logs need to be
collected on the target machine, and will remain authentic only until the
point when the superuser decides to circumvent them. Even though it seems like
a partial solution, it is still useful.
The jump-server setup can be done by putting a sort of "captive portal" on the
jump server, only allowing the user to interact with a program selecting which
server to log in to. This approach is used by e.g. https://github.com/aker-gateway/Aker.
Another approach can be similar to "virtual hosting" and NAT, where a single
jump server can have a number of IP addresses on the external interface,
mapped one-to-one to addresses of the protected servers, perhaps aided by
split DNS views. When users would log in to one of those external addresses,
the jump server would know which server the user wanted to reach and can start
recording and initiate further SSH connection to the protected server
automatically.
The challenge here is how to then link such session recordings to the session
on the target server, for both the terminal I/O and audit logs.
For specific user requirements and typical jump-server setups we can contact @anazmy, the author of Anker, linked above.
The text was updated successfully, but these errors were encountered:
Perhaps we can make SSH or whatever remote access protocol is used pass some kind of tag for us from the jump-host to the target system, so it could appear in audit logs, tied to specific session. Or, perhaps, we can do it another way, making it inform us which session ID it got.
Tlog cannot be used to record superuser sessions securely. For those sessions
another approach should be used, such as jump server. In a jump-server setup
the user first logs in to a machine which records all the terminal I/O, and
then from that machine he/she logs in to the target machine.
This allows recording terminal I/O securely. Still, audit logs need to be
collected on the target machine, and will remain authentic only until the
point when the superuser decides to circumvent them. Even though it seems like
a partial solution, it is still useful.
The jump-server setup can be done by putting a sort of "captive portal" on the
jump server, only allowing the user to interact with a program selecting which
server to log in to. This approach is used by e.g.
https://github.com/aker-gateway/Aker.
Another approach can be similar to "virtual hosting" and NAT, where a single
jump server can have a number of IP addresses on the external interface,
mapped one-to-one to addresses of the protected servers, perhaps aided by
split DNS views. When users would log in to one of those external addresses,
the jump server would know which server the user wanted to reach and can start
recording and initiate further SSH connection to the protected server
automatically.
The challenge here is how to then link such session recordings to the session
on the target server, for both the terminal I/O and audit logs.
For specific user requirements and typical jump-server setups we can contact
@anazmy, the author of Anker, linked above.
The text was updated successfully, but these errors were encountered: