Log Central
Why logging to a central repository can pay off for systems admins
August 27, 2007
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
1:40 PM -- Logging to a central repository isn't hard -- at least, it shouldn't be. I don't want to pick on Windows sysadmins, but they are always the ones I hear asking about centralized logging. This isn't their fault, nor is it that *nix (Linux, Unix, BSD, etc.) sysadmins are magically blessed with the knowledge of how to do it at birth. It's just that the core logging methods of *nix platforms (syslog) support remote logging out of the box, making it extremely easy, while Windows systems are sadly lacking in this area.
The reasons for logging to a central repository should be pretty obvious, I would hope, but let's touch on them for those Windows sysadmins out there -- um, I mean, for those unfamiliar with how centralizing logs can help.
First of all, security professionals and sysadmins are busy people. They have blogs, forums, and newsgroups to read during the time they have for their real work, like sifting through logs on a dozen or more systems each day. Logging everything to one central place gives them one place to check each day, making it easier to alternate between reviewing logs and monitoring their RSS feeds on Google Reader.
Second, attackers -- the smart ones, anyway -- like to cover their tracks. If the logs are going to a hardened, central logging host, you may just capture some of the attacker's activity before she deletes the local logs and turns off remote logging. This is also important if a server begins to have hardware or software problems that cause it to crash. You may find key clues in the central log that help explain why a server crashed and took its local logs with it.
Finally, there may be compliance reasons driving organizations to centralize their logs. With Sarbanes Oxley, for instance, the concept of separation of duties can be applied directly to logging and auditing. Sysadmins are responsible for setting up their systems to log to a central host they may not have access to, while the security engineer has direct access to the central logs for auditing purposes. The security engineer is then the person who looks for suspicious behavior that may indicate either a compromise or possible insider attacks.
I want to emphasize that the reason Windows sysadmins always ask me about logging is not due to their own shortcomings. It's a Windows operating system problem: Microsoft has not made it easy to centralize Windows Event Logs, and the tools it does provide tend to be quite bloated and expensive to implement.
In Wednesday's blog, I'll cover tools that Windows sysadmins can use to centralize their logs as they seek that logging nirvana already inhabited by their *nix brethren.
— John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Unleash the power of the browser to secure any device in minutes
September 24, 2024