Configuration

Logging/Monitoring

So what exactly do we want the login logging to do? Just every time a user logs in/logs out, or do we need more advanced capabilities? Log every command? Framework to search for suspicious commands? etc Alexr@ugcs.caltech.edu 00:25, 3 February 2007 (PST)

So at the very least, we would keep track of the auth logs- logins and su/sudo uses. We would also do syslog logging, which can provide some clues for suspicious activities. Also, there is linux process accounting in Debian- just install the 'acct' package and start writing scripts to look for fishy stuff. Process accounting can be very useful for post-breaking analysis.

It would be a good idea to run syslogng on all of the boxes and have them all log to a central log server. (checkout phpsyslogng) Silasb@ugcs.caltech.edu Wed Feb 7 23:01:37 2007

I don't like acct. The logs are easly corrupted.--Goldstei@ugcs.caltech.edu 05:26, 5 February 2007 (PST)

Silasb@ugcs.caltech.edu 23:18, 13 February 2007 (PST) -- I found this company (ZenOSS) at SCALE. There were several other projects doing similar things, but zenoss was the most impressive. The product is GPL, and they charge for enterprise support. ZenOSS essentially ties the following into a nice manageable WebApp:

• Logging.

• Prioritizes events.
• Email Notifications.
• An admin who recieves the notification and then goes to work on it can acknowledge the problem so that others are not troubled by it.

• Inventory & Configuration Management.
• Performance Monitoring.
• Reliability Monitoring.

SELinux

I have some experience with SELinux, and think we definitely should use it (maybe with grsec patches or something else too) on the authentication server (definitely), logging server (probably), and fileserver (maybe).

Debian Live

Silasb@ugcs.caltech.edu 23:18, 13 February 2007 (PST) -- The clients should be configured to PXE boot off the network, and load kernel and a readonly root filesystem from the fileserver. This readonly image will be a debian-live image. To upgrade the environment on the clients you just chroot into the image, and make your changes. The clients will be able to customize thier own image via UnionFS, in a similar manner to how KNOPPIX allows you to change things, and install/upgrade software while running on a readonly CDROM image. The included kernel will have OpenMosix extensions and Xen extentions.

Benifits

• Centralized upgrades and administration.
• If you suspect a box was rooted, just reboot it and it will come up with a clean image.
• With OpenMosix support, the clients will be a _real_ cluster.
• With Xen support, you can load a guest OS on the running client. Which can allow us to upgrade client configuration without _actually_ rebooting the client.
• The Xen support will also allow us to test new configurations before rolling them out without needing extra testing hardware.
• Others that I haven't thought of. ;)