There's a bit of a hole in open source that Red Hat's been working to fill. Well, not a hole actually, but a missing feature in access control that is required by many enterprise users.
Red Hat is working to tackle session recording, which means exactly what it says: the recording of everything a user does while working in a system. This is necessary for a variety of reasons, and is often mandated and sometimes required by law for medical and financial institutions. SysAdmins find it useful for things like monitoring what contractors do when given access to a system. And when someone makes a mistake that brings a system down, with session recording in place there's a much better chance of getting back up quickly by seeing what the user did to bring about the crash.
"If they could, they would put a camera behind the user's back and see what was going on," joked Nikolai Kondrashov, a software engineer who's working on the User Session Recording project for Red Hat, "and I guess there are some installations that do that."
Kondrashov was speaking at February's FOSDEM, the open source developers' conference which is held each year in Brussels.
"Essentially, they want everything recorded," he added. "They want it stored somewhere safe, where nobody except privileged persons can access it. They want to easily find who did what and when, and what was going on and how exactly they did it. They want to see what was actually happening."
Commercial products are available, and they approach the task from a variety of angles. Some use dedicated hardware that can be put in front of servers to intercept secure connections and record SSH sessions, database connections and the like. There are also jump servers that customers can install on their own hardware, or software meant to go directly on targeted servers.
"There are a lot of solutions, but they're pretty expensive," Kondrashov explained. "Sometimes they involve pretty involved and cumbersome licensing terms, like licensing per server or licensing per user. And you can't fix it yourself. You can't improve it, because the source is closed and you are relying on just one supplier, and if they screw up, you can't do much."
There's no ready-made open source solution, and existing tools that might at first glance seem good-to-go each comes with built-in limitations. The script command, for example, has security issues, sudo I/O logging works well but can't be streamed to a centralized location, and TTY auditing only includes input. Red Hat has used these tools to build specialized solutions in custom installations, so it can be done, "but you have to do it all yourself and it takes a little time."
What's needed is an open source application that out-of-the-box can be easily configured to meet individualized needs. To this end, Red Hat has surveyed its customers and has come up with a short list of features that are universally required. Customers need to record what the user enters, sees on the screen, executes and accesses, and to be able to quickly get it off the local machine to store securely at a central location. Customers would like to be able to view the session in real time, live as it happens and later on playback, and to be able to search, analyze and correlate the session with other events. Finally, the entire process needs to be able to be controlled centrally.
Red Hat is making progress with a project which pulls existing open source applications off the shelf and integrates them with new applications -- Tlog and Aushape -- that are under development. Although the project isn't yet ready for production, it still lacks a few needed features and needs a GUI, it's far enough along that Kondrashov was able to demonstrate it at FOSDEM.
He said that using popular existing technologies, such as Elasticsearch and its plugin Kibana, will give this approach some advantages over already available solutions when it's ready for prime time.
"We think this approach is actually better than many commercial offerings, as you can use already existing login infrastructure and you can save resources, meaning hardware resources. You don't need to add that much new capacity and you don't need that much maintenance compared to a separate system that has its own delivery and its own maintenance protocols."
Although there's a lot of work ahead to make this project production ready, as I watched a video of the demonstration, it seemed to me that a resourceful SysAdmin could already download the components and piece together a solution that might work well enough until Red Hat releases a finished product.
There's no timeline yet for a release, but when pushed at the end of his FOSDEM session, Kondrashov indicated that before it becomes available in RHEL it will be tested in Red Hat's community distribution Fedora, where Tlog is already available. "The ultimate target is RHEL, but I can't tell you the exact dates."
