I'm trying to investigate some issues that arose in a business-critical system handling medical and payment data, which is regulated by HIPAA and PCI. Recently, a vendor made changes that resulted in significant downtime, and now I'm tasked with providing forensic evidence about those changes. I have a two-hour window from four days ago, and I know some key files were altered, but I can't find out who accessed them since they've been repaired, and I lack backups or snapshots of the virtual machine.
My main question is whether the XFS file system retains enough journal logs to help me identify who made modifications to system configuration files and when. If it's insufficient for the live system, is there a way to clone it and roll it back for analysis? I've discovered that there's no SELinux logging enabled, so I'm looking for any possible leads to get to the bottom of this. The immediate goal is to determine whether the person who restarted the network manager service also edited the configuration file or if they were just caught in someone else's mistake.
2 Answers
I've dealt with similar situations before, especially in medical environments. My first suggestion would be to check your backup strategy. If you can restore the VM to just before the outage, you might see if the configuration file was already problematic. This is often a good sanity check. Remember, when making changes, it's useful to reboot systems beforehand to catch pre-existing issues. So make sure to verify your backups.
Before diving too deep, I'd recommend making a complete disk copy to safeguard your data. Have you looked at your login logs? If the file requires elevated privileges to edit and restart, you should definitely check if you have any sudo or audit logs, as those might provide a clue about who made the changes, even if they used a shared account. Also, definitely check out auditd if it's available; it can help track file modifications more effectively.
Yeah, we know it was the vendor, but they were using a shared account that's essentially a real root access. So, the login logs will give me some insight into who was connected at the time, but it won't pinpoint who changed the file. I'll look into enabling auditd for better tracking in the future.