Protect log files

[Gillian Craigie_1]

Hi,

Does anyone know of a facility which will allow a logfile to be appended to, but prevent existing data from being modified? The auditors do not like the fact that system administrators can amend logfiles.

So far our only options appear to be writing the logfiles to a write once/read many device such as a cdrom, or to have the logfiles on a seperate host which is not accessable by the users. We are running HP-UX 11.0 and HP-UX 11i.

Thanks.

[Simon Hargrave]

Ask the auditor if they're happier with administrators having the ability to modify logfiles, or maintain the systems themselves!

If there is reason to think logfiles are being amended, then disciplinary procedures should cover these - let administrators get on with their jobs!

If they really want logfiles to be non-editable, then the only way is to restrict root access! I do know of companies that have an audit department that change root passwords to allow UNIX admins on to do a piece of work then change it again! Needless to say these companies don't keep their good administrator for long!

I'd say that a WORM device isn't really a feasible solution, unless you want a potentially huge stack of CDs with logs going back to the year dot.

All opinion of course, but as far as I'm concerned if you start to limit the administrators power beyond change control, then you're on a sinking ship.

[Carles Viaplana]

If system administrators have root accounts, I think options you said are the only ones as root accounts have always all rights on all files.

Regards,

Carles

[Ralph Grothe · Accepted solution]

I pitty you if the auditors force you surrendering your root powers.

In classical Unix it's quite binary, either nothing, or all.
That's why it was so important to keep your root passwords sound and secret.

However, as there seem to appear ever more auditors who dislike these unconfined root powers, most Unices recently came up with Role Based Access Control.

I saw that there's also a HP-UX implementation.
Maybe you can find out more about it and if it suits you here?

http://docs.hp.com/en/5991-0709/ch01s01.html

[Gavin Clarke]

I suppose you could configure a loghost with auditor only access. Which you can do in /etc/syslog.conf.

Hang on though you can just change syslog.conf to stop logging briefly if you really wanted to.

Although no access to log files does seem a little heavy to say the least.

Perhaps you should look at HIDs if you haven't already.

Which logfiles do they not like admins having access to?

Having a policy of logging in as an identifiable login name and then su - root, would give you a bit of an audit trail about who was in as root.

Surely if you were up to no good you could just switch off whatever was logging. Seems like your auditors want a whole new operating system to me.

I think I'm ranting a little, administrators have to be given at least a little trust. They/we have access to all sorts of critical processes not just log files and we have a responsilbity to look after them.

I should think that these people who changed the password straight after admins logged in were creating a great deal of temptation for those admins to create back doors, which doesn't help anyone.

I shall be watching this thread with interest. Now I'm going to lie down in a darkened room for a bit.

I hope you find the answer you are looking for.

[BFA6]

Hi,

I can't think of a utility which would allow what you want.
As Gavin mentioned, so not allow users to log in directly as root, and setup individual shell histories for users when they switch ie. .sh_history..root

Ask the auditors for a utility that does what they want, after all they are the ones making the request.

Regards,

Hilary

[Bill Hassell]

I don't know of any popular operating system that can protect ANY FILE from the root administrator. Your auditors are quite unknowledgeable about the requirements for the system administrator. I understand the concern, but unles you scrap ALL your existing HP-UX systems and install B2-level secure systems (HP-UX had a system called Virtual Vault which was B2 compliant). In this system, no one had complete control of the system and some 'normal' tasks would require at least 2 or 3 different admins to perform. To properly setup such a system would require about 4-6 months and you would have to double or triple the number of system admins to keep things running.

NOTE: Even a B2 system would not meet the auditors' requirements as there nothing special about any log file. syslog.log is defined in /etc/syslog.conf or redefined in /sbin/init.d/syslogd with the -f option for syslogd. You could hook up some writable CDROMs, spend a lot of cash to have a special driver written to append to the CDROM, then have armed guards monitor the CDROM around the clock.

[Gavin Clarke]

If you have a card access scheme to get into your computer room then you could limit access to the console.

Then someone could borrow someone else's card...

Besides consoles aren't what they used to be, they are mostly LAN consoles.

I feel like I'm playing chess against myself.

[BFA6]

Bill - I like the idea about security guards watching over the CRDOMS.

Gavin - let me know if you win the chess game.

What exactly are the auditors worried about? If someone wants to do any malicious damage, if they know their stuff they will cover their tracks. If you manage to tie the system up as securely as the auditors want, no-one will be able to their jobs.

Hilary

[MarkSyder]

Hilary - what are the auditors worried about? Justifying their salary!

Mark Syder (like the drink but spelt different)

[Ralph Grothe]

I think these auditors are as Bill said
folks who don't know what requires administering a Unix system.
Even if you could lock out your root account almost completely, what's it worth in the end?
Any decent root kit is wiping out its traces.
In fact the latest breed of root kits have reached such a high sophistication that even well devised IDS and most alert sysadmins would have a hard and long time before they even detected a compromise.

[Gillian Craigie_1]

Thanks for all your replies. I totally agree with what you have said, but unfortunately its not up to me! I'd like to pass them on to the auditors but I don't think that will satisfy them.

To answer some of your questions - they have not specified any logs in particular - but it looks like any logs which capture user logon/activity, system logs, I/O device logs, network management logs.
We currently ensure that all a administrators log on as ourselves before switching user to root.
The auditors have already asked us to sign a form every time we do this and state the reason for this - very tedious, and to be honest just encourages us to login once as root then carry out multiple tasks which wont be logged anyway.
I am also not supposed to know the root password, one of my colleagues supposedly logs in for me each time, but thankfully my manager does not enforce this and the auditors haven't quite got round to checking this yet.

I will look into RBAC and HIDS, thanks to Gavin and Ralph.

It looks like we will probably be transferring our logfiles to a separate host which is only accessible by a limited number of users, but how workable this is I don't yet know.

Once again, thanks for your comments.

[Rick Garland]

Almost sounds like a case for the sudo utility, at least one possibility for the use of sudo.

You are not limited in your sys admin powers but you do provide greater information flow to the auditors - lots of logs files!

[Ronaldinho]

Hi Gillian,
Sounds like you got a nasty auditor indeed. If you are looking for a mechanism whereby the standard of proof that a file has not been tampered with is greater than normal then you could make regular writes from your logfiles to a different server that your sys admins donâ t have access to (maybe using a cron).
It should give some sort of assurance that log tampering can be detected but it's by no means absolute.

Hope you keep you're auditors happy!!!

John :-)

[Bill Hassell]

The syslog file is commonly sent to a separate server (see /etc/syslogd.conf and the man pages) for security. The rest of the files (wtmp, btmp, sulog, etc) will have to be cron-copied to another server every few minutes. It would be best to use rsync to avoid excessive network traffic.

It is reasonable to require login as a normal user and then su but as mentioned, sudo is MUCH MORE preferred in the security community. The reason is that you can limit the commands allowed for specific users and every command is logged. As far as other users logging in as root, there are some sysadmins (totally paranoid) that do not allow root login ever and enforce this by changing the root password every 5 minutes to another (unknown) random string. Sysadmins must use sudo for all tasks.

As you are seeing, human nature takes over when unreasonable and inconsistent rules make the job intolerable. Users will secretly share passwords, they will wipe out or overlay .sh_history (in case anyone is looking), they will (if alloed) use sudo to run /usr/old/bin/sh which is the Bourne shell to by pass .sh_history but still have root access.

And of course, the auditors have told your managment that additional people are required to check on everything everyday, to read every signed paper about root access for appropriateness, to have regular reviews of all sysadmin tasks, to prepare reports for the auditors and upper management, and if these audits are for SOX compliance, upper management must sign off on all the reports indicating that they understand and approve each task. (they don't? hummmm)

And of course, all these requirements must be applied to a PC-based and mainframe systems too (they aren't? hummmm).

[Ronaldinho]

Hi Gillian,
Did your auditors accept any of the responses?

Please remember to assign Points.