So by default when you forward logs to a syslog/rsyslog server all the logs end up in the same file (ususally configured to go to the messages file). Sometimes one may prefer to forward logs from a particular server to a separate logfile. I know for a fact that my sometimes friends in our info-sec group prefers this setup.
While managing such a setup for more than a handful of hosts would probably be a nightmare, its not actaually hard to setup on the most basic level.
First create a custom filters.conf (or whatever you want to name it) in your /etc/rsyslog.d directory. Below is the file that I created.
Note that you will need to include two lines in your file for each host, one with the specific file/location that you want to send your filtered log messages, and a second line that directs rsyslog to discard any messages from the specified hosts once they have been logged to the specified locations. This keeps these messages from ending up in the messages file as well as the file defined in your filter file.
Let me start off by saying that I am not a fan of disabling ctrl+alt+delete, especially if you do not have physical access to a server. Sometimes the old three finger salute is the best and quickest method to reboot a locked and unresponsive Operating System. Regardless of this fact, some Info Sec folks think that disabling this functionality is a good idea for security. So for their sake, I will show you how to do it.
First ssh into your server and become root and change directory to what is shown below.
[root@ip-172-31-22-45 ~]# cd /etc/init
Now copy the file below exactly as I have illustrated. You do not want to try to modify the original file as it could be overwritten by Upstart.
Ever heard of AIDE, neither had I. Apparently its a simple intrusion detection application that can be used to monitor file changes. It can be confired to monitor permission, ownership, timestamp, or content changes.
Lets install it. Its in the stock Redhat repos, so its a piece of cake to install via yum.
[root@localhost ~]# yum -y install aide
Once installed, you can tweak the config file (/etc/aide.conf) to your liking. The stock config is pretty robust, so I am going to trim it down a bit and just monitor /etc for permission changes, and /bin for what are defined as normal changes. Normal looks at file hashes to see if the files have been modified.
/bin NORMAL /etc PERMS
Now lets start aide
[root@localhost ~]# aide –init
AIDE, version 0.15.1
### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
Now this part is silly, we need to rename the database created above to the name that aide is configured to use.
In my previous post I went over standard filesystem attibutes in Linux, and how to set and view those attibutes with lsattr and chattr. You can view that post here if you are interested.
In this post we are going to go over extended filesystem attibutes. Now there is not much to this as you are probably not going to ever have to use these settings. That being said, its not a bad thing to be aware of.
Attribute names are strings that can be set and configured at will using the setfatr command. They can be viewed with the getfattr command. There are 4 namespaces of attibutes, security, system, trusted, and user.
When using getfattr ( which I pronounce as getfatter) the -d option dumps only user namespace attibutes. The rest of the namespace attributes can be viewed by using the -m option along with the namespace name. In the example below you can see that there are no user namespace attibutes set on my anaconda-ks.cfg file, however there are attibutes set in the security namespace.
Hey look at this spooky key. Don't be frightened little one. Nothing scary is going to happen to you here. This is a safe place. As a matter of fact, if you stick around you might just learn a thing or two. A thing or two about GPG!
First off do any of us really know what GPG stands for? Well yes we do! It stands for GNU Privacy Guard. RPM Package creators use GPG to apply a digital signature to their packages. If a package was tampered with, then its GPG signature will no longer match what was placed in the original package.
First off to check what keys you have installed on your Linux server you can run the following rpm command as show in the example below.
Neet I have three keys installed. But lets say want to install another one. Well I can do so with the command below. In this example I have navigated to /etc/pki/rpm-gpg and am going to install the redhat beta key on my server.
Hey that was fun. Now lets get our hands a bit dirtier.
Want to get more information on a specific key. Then this command is your huckleberry. Here you can see that this is the pubkey for the EPEL repo.
[root@ip-172-31-22-45 rpm-gpg]# rpm -qi gpg-pubkey-0608b895-4bd22942 Name : gpg-pubkey Relocations: (not relocatable) Version : 0608b895 Vendor: (none) Release : 4bd22942 Build Date: Sat 14 Jun 2014 09:13:58 AM EDT Install Date: Sat 14 Jun 2014 09:13:58 AM EDT Build Host: localhost Group : Public Keys Source RPM: (none) Size : 0 License: pubkey Signature : (none) Summary : gpg(EPEL (6) <firstname.lastname@example.org>) Description :
To verify signature of a downloaded package, use the rpm command as shown below. In this example I have highlighted the key that was used to sign this package.
# rpm -vK nautilus-dropbox-1.6.0-1.fedora.i386.rpm nautilus-dropbox-1.6.0-1.fedora.i386.rpm: Header V3 RSA/SHA1 Signature, key ID 5044912e: OK Header SHA1 digest: OK (a4d51906633f92913db075ba33946f50999c245e) V3 RSA/SHA1 Signature, key ID 5044912e: OK MD5 digest: OK (1b8ff7abc18f68bf274e24fc57fd3a87)
Using the bolded information in the example above, I can then use this information to track down the exact key that was used to sign the package.
Lets face it, one of your users needs to have a package installed on a system, you tend to do it for them. That is, as long as the package looks safe. Sure, your not going to install an rpm that is clearly dangerous, but as long as the package name looks reasonable and you trust the user, you might actually just go ahead an install it for them without thinking much about it. Hell, I know that I have done the exact same thing from time to time. And I have done it with an unsigned package.
"Sure you need this Oracle thing installed on this database server?"
"You got it directly from Oracle right?"
But honestly, this is a very bad practice as you have no idea what the RPM is installing, and what its pre and post scripts might be doing to your system. Using the command below, you can inspect a packages post and pre install scripts to see if they are doing anything funny. In this instance I am taking a look at the dropbox package for my little Eeepc.
If you have already installed a package and want to see what its pre and post install scripts did. You can run the command above using the installed package name. Note that you will drop the "P" from the command. See my sendmail example below.
In addition to checking the pre and post scripts, you also want to check to see if the rpm has any triggers. What are triggers you ask? Well they are extensions to the normal install scripts, and they may often call for the installation of another package or the execution of a command. Just look at all the triggers that fire when you install sendmail.
Obviously you also want to check to see what files are actually part of a package. This can be accomplished with the query and list arguments seen below. Add the "P" argument if the rpm is not already installed. In this case I have already installed sendmail, so I exclude the "P" from the command.
So whats the moral of the story here. Well its really not that hard to take a minute and look under the covers and make sure that the packages that you are installing are not harming your systems. Is definetly worth 5 minutes of your time. Might just save your behind.
The YUM security plugin is a package that allows you to search specifically for security patches applicable to a Redhat/Centos server. This functionality comes in very handy when having to cross reference CVEs to Redhat Security Advisories (RHSAs). If you work closely with anyone in an information security role, you already know how vital functionality is.
Before you can begin you need to make sure that you have the plugin installed. Use the command below to install it.
# yum -y install yum-plugin-security
Then you can use the plugin to get a overview of the security updates availible for your system.
# yum updateinfo
Updates Information Summary: available 3 Security notice(s) 1 Important Security notice(s) 2 Moderate Security notice(s) 12 Bugfix notice(s) 1 Enhancement notice(s)
You can get a specific list of updates, sorted by security advisories, bug fixes, and enhancement advisories.
# yum updateinfo list
To get more specific information on a RHSA and the CVEs that it applies to, you can search by RHSA as seen below.
# yum updateinfo RHSA-2014:0771
Need to see what patches are required to address a certain CVE, then this next command is for you. Trust me this one is useful as it gives you a list of all required packages that address that CVE.
Want to see a list of all fixes by severity. Then you can use the command below. Note that I am using important as my severity as there are no critical updates that are applicable to my test system at this time.