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.
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.
Hey no changes. Now lets monkey with something and see if aide catches it. In this example we are creating a new file in /etc. As seen below aide catches the new file and reports on it.
[root@localhost ~]# touch /etc/aide.test.change [root@localhost ~]# aide –check AIDE 0.15.1 found differences between database and filesystem!! Start timestamp: 2014-07-15 19:51:14
Summary: Total number of files: 5054 Added files: 1 Removed files: 0 Changed files: 0
————————————————— Added files: —————————————————
added: /etc/aide.test.change
So now lets re-initialize the database, which is pretty much a snapshot.
[root@localhost ~]# aide –init
AIDE, version 0.15.1
### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
Now lets change the permissions on our test file and see if aide catches the change. I'll spare you the suspense and let you know that aide did its job. See below.
[root@localhost ~]# chmod 777 /etc/aide.test.change [root@localhost ~]# aide –check AIDE 0.15.1 found differences between database and filesystem!! Start timestamp: 2014-07-15 19:54:09
Summary: Total number of files: 5054 Added files: 0 Removed files: 0 Changed files: 2
Now aide on its own is just a simple tool, but run via cron with a bit of tuning and a bit more logic behind it and I can see it being a very useful tool. Looking forward to playing with it more.
Ok, before you even attempt to read this post, I am assuming that you not only understand standard UNIX file permissions, but that you also understand special file permissions. What are special file permissions you ask. Well you know them as setuid, setgid, and the stickbit. If you don’t know what these things are then I will give you a very brief introduction.
Setuid – when set on a file, runs a command as root, a good example of this is the password command as shown below.
[root@localhost ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 27156 Aug 3 2013 /usr/bin/passwd
Setgid – when set on a file, elevates permissions to the group ownership of a file. When set on a directory, causes all files created in that directory to be inherit group ownership from the directory.
Sticky Bit – when set on a directory, blocks a user from renaming or removing a file that they do not own.
Now lets use the find command to find files on our linux box with special permissions.
To match a special permission with a specific octal number specify the octal number as shown below. Note that this command does not return anything at all as there are no files on my system with the perms 4000.
[root@localhost ~]# find / -perm 4000
To match the permissions on a file using a specific prefix use the ‘-‘ switch as shown below. Its basically a wildcard search, which searches on the fields that you specified.
[root@ip-172-31-22-45 ~]# ls -l /bin/cgexec
-rwxr-sr-x. 1 root cgred 16384 Dec 2 2013 /bin/cgexec
Now lets get silly and try to match two octal values at once. This time we are going to search for files where both the setuid and setgid bits are set. As we know 4 + 2 = 6, so our command is as shown below
[root@ip-172-31-22-45 ~]# find /bin -perm -6000 | head -n 3
Note that this command does not return anything at all. However if we modify it a bit so that it searches for files that either have the setuid or the setgid bit set. To do this we use the ‘/’ modifier as shown below in my awesome example.
To review. when using find if you do not specify any switches or options when searching for files by permissions, then you are attempting to do a specific match for files with those exact permissions. When you use the ‘-‘ option you are searching for files that match on a specific field. When you use the ‘/’ switch you are basically doing a wild card logical OR search. Use this option when you are searching for more than one type of special permission.
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.
Hello again earthlings. The fatmin returns once again to dispense a bit of wisdom. This handy one-liner is a command that for the life of me I cannot remember.
Our story begings when building your kickstart config and post-install config files you are going to need to set the password for at least one user (being root). If you are like me your configs add all sorts of users. As you know you cannot just stick the password for these users into your config files in plain text, rather you need to encrypt them via ssl.
The command to do so is below.
openssl passwd -1
At this point you will be prompted to enter the users password — twice. Then the command will spit out your ssl encrypted password which you can then shove into your config files.
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.
