On 08/09/16 23:57, Paul Robert Marino wrote: > This thread raises some interesting point but I've seen a few > misconceptions in it too > > first let me clear up the misconceptions. > 1) busy box is meant to make the footprint on an appliance or live > "CD" type distro smaller it is not for security. Rootkits that replace > busy box have been seen in the wild on appliances in the past, so its > not necessarily a good answer to prevent rootkits. Suggestion: Have a statically linked busybox binary stored on an offline device which is only activated when absolutely needed. And with offline, I mean something which is disconnected physically from the system when not being used. > 2) you really don't need root to be writable in production on any > system as long as you've laid out your logical volume or partitions > correctly and just add a few simple operational procedures when you > update or modify configuration files. As far as updates go you can > still do it by remounting (mount -O remount) the filesystem as read > write first,run your updates, then remount again as read only. I've > been doing this on secure systems for over 20 years and its quite > effective in preventing about 40% of root kits from infecting a > system. In fact in the cloud you should make your instances as > stateless and read only as possible. you do this by only doing updates > on the VM you use to create your image and not the production VM's > instead you should just replace them when you are ready to update this > works well with thing like AWS autoscaling and other similar > solutions. in reality on most systems only /var, /tmp (preferably > tmpfs), and maybe /home need to be writable in production. Good points! These hardening steps will definitely give results. Another thing to consider is to configure Tripwire. That is a tool which creates a signature database of all configured files and tracks them. Log files can also be tracked, where it allows log files to be appended but not modified since last "check-point" (should be run at least once per day). The downside of Tripwire is that it requires you to update the signature database each time you do some yum update/install operations. And such updates requires an additional password to unlock the signature database for write access. Each time the "check-point" run has completed, it will provide a list of all unexpected modifications on the system. Tripwire is found in Fedora EPEL. > 3) SELinux secures system processed but not user executed commands for > that you need apparmor which is not implemented in RHEL yet. AppArmor will most likely never see the light in RHEL. Because SELinux can do similar things, with a far better fine grained control. And if you instead of choosing the targeted SELinux profile (which is the default) and use the strict profile instead, all applications running on a system must have a SELinux policy defined. This does require some additional efforts to configure, but once done it is much harder to do things on the system not being approved in advance. -- kind regards, David Sommerseth