0

In RHEL5 Security Guide using of AIDE for checking software integrity is recomended. And also built-in RPM integrity checking functionality. But frequent checking can be resource demanding and rare might not be very useful. On the other hand, constant audit of crucial parts is relatively cheap. And it still ensures integrity to some extent.

So basically my question is: in which cases integrity checking (AIDE, RPM or something new) is better, than an audit?

UPD: Just to clarify a bit. By "audit" I mean RHELs audit service based on specific auditd daemon. It can be properly adjusted to supervise files and directories constantly. To fail an integrity check, file should be modified somehow, and this would be noted by the audit system. So why bother with consequences (e. g. a failed checksum), when we can trace the reason for that modification?

akalenuk
  • 533
  • 2
  • 6
  • 16

1 Answers1

1

I don't know whether this question can be meaningfully answered, though I'm not quite sure enough of that to vote to close it.

But I do think that in any cost-benefit analysis, you mustn't forget the benefit: which in this case, is the avoidance of the cost of failure. You say that frequent checking can be "resource demanding", and this may well be so: but how resource-demanding is rebuilding your backend infrastructure from golden backups because some intrusion occurred?

How much you spend on securing a system is a function of what the system is worth, in terms of integrity and functionality. For myself, any machine that'll be exposed to the internet gets daily tripwire checks, and reports by email. Nearly everything syslogs to a centralised log host, off-system; any footprints an intruder might generate on the way in can't be removed from the remote syslogger. More sensitive machines may also get RPM integrity checks, selinux enabled (with all the horrendous hassle that that entails when running non-standard software), tripwire running from read-only media, and even more integrity protection. It all depends on how much the machine is worth.

Edit: I hadn't understood that you meant the auditd software service, rather than the general concept of auditing, it's true, but even if I had my answer would have been the same: defence in depth, the depth justified by the value of the asset. If there was a single, simple, cheap, absolutely reliable service called complete-securityd, we'd all be running it; as there isn't, the more precautions you take the less likely a compromise is to (a) happen, and (b) go undetected when it does.

Since you ask about types of intrusion that auditd might miss and tripwire might catch, the customised kernel module exploit is one such, because tripwire can be run from read-only media and kernel, and auditd can't.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Daily checks are fine, but one can intrude the system and wipe the traces much faster then in a day. So we still have to audit systems vulnerables. Even if intruder leaves some marks, we would get both integrity check reports and audit logs. Why not only logs? Is there a way to compromise an audit system, which wouldn't work on tripwire? – akalenuk Apr 25 '13 at 10:26
  • See edit above on centralised forensic log host. Any local auditing tool - tripwire, AIDE, or another - has the issue that you can't properly evaluate the trust of the platform on which you're standing; running tripwire from RO-media makes it harder for an intruder to bypass that, but custom kernel modules can still evade the controls. Booting from an off-system kernel (rescue media), and running tripwire from there, however, would be very difficult for an attacker to evade. It's a horrible pain to do, but if I was securing eg a CA-root host, I might go to those lengths. – MadHatter Apr 25 '13 at 10:31
  • I believe, I haven't made my point clear from the beginning. My bad. By "audit" I mean specific service (I can see one in RHEL and Fedora, but not, for instance, Ubuntu) called "audit". It can be set to monitor files and directories on the go, storing a lot of evidence in its log. I'm totally pro security measures at general, I just want to completely understand an appliance of both constant audit and integrity checks approaches. – akalenuk Apr 25 '13 at 11:33