Once you have done the previous workarounds and have define your security policies (whatever, complete or incomplete, a book or just a page) on people and on system. Your next concern should be how to respond?
Before proceeding further, let's recall what basics we are including in our policy.
For People & Systems, you have to clearly define activities to manage human 'incidents' or 'events'. You have to define who is incharge of what? ITIL defines it with CI and ownership but this time you have to calculate this in terms of security. Who is incharge of what, who is going to make final decisions on false alarms and when you are going to mirror your breached system disks and notify enforcement agencies !! You have to monitor system activities on regular interval, set up a central log server as we discussed, use logwatch to ease your life (+ other than server farms network, you can setup delay pools on your squid for your users) and the golden rule backup backup backup.
Now asap you get the warning signals like services mysteriously dying or erased tracks or spikes in bandwidth, Don't offer services from the system, boot from verified media to verify breach, analyze logs of remote logger and match if the same things happened with local logs or not ! Check file integrity against read-only backup of your rpm database. make image of your system for forensics, wipe out your box, reinstall, harden and restore from backup. You're up again.
Before processing further, let's go to # and make sure yum.conf is having
gpgcheck=1
How to - Integrity Checking:
First of all define policy, define a general strategy for implementing integrity checking. You have to install AIDE
# yum install aide (it's not installed by default)
Remember, the prelinking feature which is enabled by default can interfere and can produce false alarms in your integrity checking, so disable prelinking by writing PRELINKING=no in /etc/sysconfig/prelink and restore your binaries to a non-prelinked state by running
# /usr/sbin/prelink -ua
now customize /etc/aide.conf according to your requirements. Default one is fine for most of us.
Generate a database-
# /usr/sbin/aide --init
(will be written to /var/lib/aide/aide.db.new.gz)
Install it # cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Wanna check?
# /usr/sbin/aide --check
now before doing anything else, copy /etc/aide.conf /usr/sbin/aide (yes), and the newly generated database to a read only remote media. On any unexpected output on checks you can campare your local db with remote read only db and files to be sure that everything is fine.
Implement periodic checking -
10 2 * * * root /usr/sbin/aide --check
On other side you can verify package integrity of installed rpms against your RPM db
# rpm -qVa
don't panic, the "c" in second column says that it's a configuration file and these files are meant to be changed. You can exclude config files by -
# rpm -qVa | awk '$2!="c" {print $0}'
Red Hat recommends a matrix for check point, this is extremely helpful always, whether you're going to harden your system or doing the chorus. It ask you to define following access controls and their implementations -
Application, PAM, xinetd, libwrap, SELinux and netfilter
while implementing security with this matrix, remember that every unaccountable resource access is a breach of your security policy.
Let me do the fault analysis with a classic example I faced while working for a client. I faced a frequent ticket from an application team that, their common user is not able to do the passwordless ssh. My team resolved the issue, everything was okay but only for a short time and then boom! the problem was there once again. It happened several times and draw everyone's attention. Since different members of Unix team resolved the issue all the time, the root cause was not identified in 2nd or 3rd occurrence.
A user was creating this by playing with home directory's permissions !! That was identified by 1. Characterizing the problem (frequent changes of permission) 2. Reproducing the problem (by himself, lol) and 3. Analyzing and finding further information. In this case the permissions were resetted and the user was warned not to do this and when he repeated it 3rd time his TL and manager were informed. This finally resolved the issue.
Other than this, practically you can gather data with strace (# strace -o outputfile command), you can open a terminal to continuously display your log(s) as the scroll (# tail -f logfile), and can add --debug option in application (along with *.debug in your syslog.conf). You can install sysstat RPM which will provide you sar. SAR is configured bydefault to run sa1 in every 10 minutes and to pass options to sadc. Now the sa2 runs at night, it runs sar which reads the sadc database. Both binary db and sar reports (human readable) can be found in /var/log/sa.
Along with that when you're deploying a new system, at that time (or at some point later) you can manage account resource limits with PAM by -
/etc/security/access.conf is configuration file for pam_access.so, that can be used to restrict access to bo from only certain terminals or type of terminals.
/etc/security/time.conf is configuration file for pam_time.so, it can be used to restrict time of day for a user to allow access to box or run certain commands.
/etc/security/limits.conf is conf file for pam_ limits.so and can be used to limit the number of processes a given user may create, the amount of CPU time a process may consume, the default nice value for a process and other limits.
Do experiments with these things and explore the real power of your box.
Reference: Red Hat and NSA guidelines
