RHEL6: Using Advanced Log File Filtering in Rsyslog

100-8591So 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.

[root@ip-172-31-21-28 rsyslog.d]# cat filters.conf
:fromhost, isequal, "ip-172-31-25-104.ec2.internal" /var/log/ip-172-31-25-104.ec2.internal/messages
:fromhost, isequal, "ip-172-31-25-104.ec2.internal" ~

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.


Related articles

RHEL6 – Introduction to IPtables, Part II
HomeLab: Basic Syslog Configuration on Cisco Catalyst Devices
RHEL6- Getting Up Close and Personal With Rsyslog

Introduction to AIDE – Advanced Intrusion Detection Environment

Wally_Gator_PhotoEver 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.

[root@localhost ~]# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz


Now lets check for changes.

[root@localhost ~]# aide –check

AIDE, version 0.15.1

### All files match AIDE database. Looks okay!

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

  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.


Don't forget to overwrite the old database.

[root@localhost ~]# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
cp: overwrite ‘/var/lib/aide/aide.db.gz’? yes

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

  Total number of files:        5054
  Added files:                  0
  Removed files:                0
  Changed files:                2

Changed files:

changed: /etc/aide.test.change
changed: /root/.mozilla/firefox/8u03e3hs.default/sessionstore.js

Detailed information about changes:

File: /etc/aide.test.change
 Perm     : -rw-r–r–                       , -rwxrwxrwx
 ACL      : old = A:
                  D: <NONE>
            new = A:
                  D: <NONE>

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.

Related articles

How To Install Aide on a DigitalOcean VPS
RHEL6 – How to Setup an Anonymous Download Only FTP Server

Finding Files with Special Permissions in Linux

Special-k-diet-1Ok, 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 ~]# find /bin -perm -4000 | head -n 5

As shown below, this command returns us all files in the /bin directory with the setuid bit set. In octal 4 is setuid.

[root@ip-172-31-22-45 ~]# ls -l /bin/ping
-rwsr-xr-x. 1 root root 40760 Sep 17  2013 /bin/ping

The next example returns us all files in /bin with the setgid bit set. Note that the octal value of the setgid bit is 2.

[root@ip-172-31-22-45 ~]# find /bin -perm /2000 | head -n 3

See I told you so…

[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.

[root@ip-172-31-22-45 ~]# find /bin -perm /6000 | xargs ls -l
-rwxr-sr-x. 1 root cgred 16352 Dec  2  2013 /bin/cgclassify
-rwxr-sr-x. 1 root cgred 16384 Dec  2  2013 /bin/cgexec
-rwsr-xr-x. 1 root root  77336 Apr 10 04:50 /bin/mount
-rwsr-xr-x. 1 root root  40760 Sep 17  2013 /bin/ping
-rwsr-xr-x. 1 root root  36488 Sep 17  2013 /bin/ping6
-rwsr-xr-x. 1 root root  34904 Mar  5 07:21 /bin/su
-rwsr-xr-x. 1 root root  53472 Apr 10 04:50 /bin/umount

In this example below I am searching for files that either have the setuid (4), the setgid (2), or the stickybit (1) set.

[root@ip-172-31-22-45 ~]# find /bin -perm /7000 | xargs ls -l
-rwxr-sr-x. 1 root cgred 16352 Dec  2  2013 /bin/cgclassify
-rwxr-sr-x. 1 root cgred 16384 Dec  2  2013 /bin/cgexec
-rwsr-xr-x. 1 root root  77336 Apr 10 04:50 /bin/mount
-rwsr-xr-x. 1 root root  40760 Sep 17  2013 /bin/ping
-rwsr-xr-x. 1 root root  36488 Sep 17  2013 /bin/ping6
-rwsr-xr-x. 1 root root  34904 Mar  5 07:21 /bin/su
-rwsr-xr-x. 1 root root  53472 Apr 10 04:50 /bin/umount

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.

Related articles

CVE-2014-0907 – SetUID/SetGID Programs Allow Privilege Escalation Via Insecure RPATH In IBM DB2
setuid/setgid binaries in Debian’s Wheezy release?
Learn octal file permissions easily with stat

RPM Package Inspection for Fun and Profit

6a00d8341c562c53ef01538f8abd65970b-800wi"Whats in the box" — David Mills

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.

[root@localhost ~]# rpm -qp –scripts /root/Downloads/nautilus-dropbox-1.6.0-1.fedora.i386.rpm

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.

[root@localhost ~]#rpm -q –scripts sendmail-8.14.8-2.fc20.i686


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.

[root@localhost ~]# rpm -q –triggers sendmail-8.14.8-2.fc20.i686
triggerun scriptlet (using /bin/sh) — sendmail < 8.14.5-3
/usr/bin/systemd-sysv-convert –save sendmail >/dev/null 2>&1 ||:
/bin/systemctl enable sendmail.service >/dev/null 2>&1
/bin/systemctl enable sm-client.service >/dev/null 2>&1
/sbin/chkconfig –del sendmail >/dev/null 2>&1 || :
/bin/systemctl try-restart sendmail.service >/dev/null 2>&1 || :
/bin/systemctl try-restart sm-client.service >/dev/null 2>&1 || :
# workaround for systemd rhbz#738022
/bin/systemctl is-active sendmail.service >/dev/null 2>&1 && \
        ! /bin/systemctl is-active sm-client.service >/dev/null 2>&1 && \
        /bin/systemctl start sm-client.service >/dev/null 2>&1 || :

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.


[root@localhost ~]# rpm -ql sendmail-8.14.8-2.fc20.i686


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.


Related articles

RHEL6 – Simple Postfix Configuration
RHEL6 – Common Postfix Server Roles
Configure sendmail as a client for SMTPs
Sendmail Server

Enycrypting Passwords Via SSL for Redhat Kickstart Configuration Files

MummyHello 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.

Related articles

Really Awesome Network Config Differ Tricks we use to forget
Strategies to establish secure password storage systems
HomeLab: Simple SSH Setup on a Cisco Router
Re: Sound Wallet – Audio Cold Storage – Your private key as .wav, CD, or a Record