How to generate an MD5sums file of packages

Start by querying the Red Hat package manager

rpm -ql coreutils | grep bin > files1

This gets a listing of all the executables in that rpm, dumping them into a file called files1.

Next, copy the file to a file called “file2”, open up file 2, and go through it, deleting every line that contained a file rkhunter had told you about (there were several executables in coreutils that didn’t get updated as a result of this bugfix).  At this point you have a file with all the files in the package, and a file with the all the files in the package that DIDN’T change. Next, run the following command:

diff file1file2 | grep \< | cut -d \< -f 2 > changedfiles

This command takes all the lines in file1 that aren’t in file2 and dumps them into a file called “changedfiles”.  Unfortunately, it results in a leading whitespace in each line, which can be manually removed since there probably aren’t that many lines.  The number of lines should be equal to the number of files that rkhunter warned you about.

Using this file, run the following bourne shell script to get a checksum of all the files into the file called “md5sums”:

#!/bin/sh

FILELIST=`cat changedfiles`;
for FILE in $FILELIST
do
md5sum $FILE » md5sums
done

Finally, compare the checksums and md5sums against RHN, made sure they were all good.

md5sum -c md5sums | grep -v OK

No news is good news at this point, it means that all the files matched, so go ahead and update rkhunter’s database with the current hash values.

Red Hat Shenanigans

An “update” or “patch” in Linux is just a file that overwrites the old file, so it will have a different hash value than the old file. Rootkit Hunter will warn you about this, and it gets annoying!

The procedure for this sort of event is as follows:

  1. Look at the files that rkhunter tells us have changed, and try to figure out what package they’re in.  We do this by using the —whatprovides flag in the rpm command.  For the /bin/basename file, we would do: 

    [root@boxname ~]# rpm -q --whatprovides /bin/basename 
    coreutils-5.97-23.el5_4.1


    We can see from the output that that file is part of the coreutils package.
  2. Query the rpm database to find out when the coreutils package was last updated: 
    [root@boxname ~]# rpm -q --last coreutils 

    coreutils-5.97-23.el5_4.1 ... 04:36:11 AM PDT


    We can see it was last updated at 4:36 AM this morning.
  3. Now we need to know whether or not it was supposed to be updated.  If we’ve received an RHN email saying that there’s a coreutils update available (it might even list the box by name), we can be pretty confident that the update is legit.  If not, we log into RHN and check the Event History for this machine (click on the machine in the list you see under “Systems”, click the “Events” tab, and click the “History” tab under that.)  If we see something like: 
    Errata Update: RHBA-2009:1511-1 - coreutils bug fix update scheduled by (Red Hat)


    with a green check mark next to it, it’s clear that RHN successfully applied the update to the coreutils package at 7:36 AM eastern time.  Since this matches the time in our query from step 2 (we’re off by a few seconds, but that’s probably okay), we can be pretty sure that the update is legit.  If we REALLY want to be sure, we can search for the coreutils package on RHN, look at the file listing, check the md5sum listed for the /bin/basename file, and compare it to the md5sum of that file on the local box (remember rkhunter uses sha1sum, so we would need to manually generate the md5sum using the “md5sum” command).  If they match, we know for sure we’re okay.
  4. Once we’re sure the file(s) are legit, we update the hashes in the rkhunter database using rkhunter --propupd.

The value of education

No matter how much you spend on any piece of technology hardware (or software) your company buys, it is only as good as it’s configuration…

How to generate an MD5sums file of packages

Start by querying the Red Hat package manager

rpm -ql coreutils | grep bin > files1

This gets a listing of all the executables in that rpm, dumping them into a file called files1.

Next, copy the file to a file called “file2”, open up file 2, and go through it, deleting every line that contained a file rkhunter had told you about (there were several executables in coreutils that didn’t get updated as a result of this bugfix).  At this point you have a file with all the files in the package, and a file with the all the files in the package that DIDN’T change. Next, run the following command:

diff file1file2 | grep \< | cut -d \< -f 2 > changedfiles

This command takes all the lines in file1 that aren’t in file2 and dumps them into a file called “changedfiles”.  Unfortunately, it results in a leading whitespace in each line, which can be manually removed since there probably aren’t that many lines.  The number of lines should be equal to the number of files that rkhunter warned you about.

Using this file, run the following bourne shell script to get a checksum of all the files into the file called “md5sums”:

#!/bin/sh

FILELIST=`cat changedfiles`;
for FILE in $FILELIST
do
md5sum $FILE » md5sums
done

Finally, compare the checksums and md5sums against RHN, made sure they were all good.

md5sum -c md5sums | grep -v OK

No news is good news at this point, it means that all the files matched, so go ahead and update rkhunter’s database with the current hash values.

Red Hat Shenanigans

An “update” or “patch” in Linux is just a file that overwrites the old file, so it will have a different hash value than the old file. Rootkit Hunter will warn you about this, and it gets annoying!

The procedure for this sort of event is as follows:

  1. Look at the files that rkhunter tells us have changed, and try to figure out what package they’re in.  We do this by using the —whatprovides flag in the rpm command.  For the /bin/basename file, we would do: 

    [root@boxname ~]# rpm -q --whatprovides /bin/basename 
    coreutils-5.97-23.el5_4.1


    We can see from the output that that file is part of the coreutils package.
  2. Query the rpm database to find out when the coreutils package was last updated: 
    [root@boxname ~]# rpm -q --last coreutils 

    coreutils-5.97-23.el5_4.1 ... 04:36:11 AM PDT


    We can see it was last updated at 4:36 AM this morning.
  3. Now we need to know whether or not it was supposed to be updated.  If we’ve received an RHN email saying that there’s a coreutils update available (it might even list the box by name), we can be pretty confident that the update is legit.  If not, we log into RHN and check the Event History for this machine (click on the machine in the list you see under “Systems”, click the “Events” tab, and click the “History” tab under that.)  If we see something like: 
    Errata Update: RHBA-2009:1511-1 - coreutils bug fix update scheduled by (Red Hat)


    with a green check mark next to it, it’s clear that RHN successfully applied the update to the coreutils package at 7:36 AM eastern time.  Since this matches the time in our query from step 2 (we’re off by a few seconds, but that’s probably okay), we can be pretty sure that the update is legit.  If we REALLY want to be sure, we can search for the coreutils package on RHN, look at the file listing, check the md5sum listed for the /bin/basename file, and compare it to the md5sum of that file on the local box (remember rkhunter uses sha1sum, so we would need to manually generate the md5sum using the “md5sum” command).  If they match, we know for sure we’re okay.
  4. Once we’re sure the file(s) are legit, we update the hashes in the rkhunter database using rkhunter --propupd.

The value of education

No matter how much you spend on any piece of technology hardware (or software) your company buys, it is only as good as it’s configuration…

How to generate an MD5sums file of packages
Red Hat Shenanigans
The value of education

About:

Feralo is the creative portfolio of Noah Spahn. Spahn is a painter with degree in Studio Arts from Biola University, a deep interest in several marked periods of Art History, and Artists ranging from Caravaggio to Immendorf.

His work is typically a veiled glimpse into some facet of his current musings. The mediums used vary as much as their application, whilst the human form is generally the vehicle. Themes may include transcendental aesthetics or the rejection of visceral urges amidst the complexities of commonplace social environs. He has also been known to produce the occasional 'automatic painting', the interpretation of which probably lies in the realm of his unconscious.

During his 25 year career as an Artist, Spahn has worked as a commissioned limner, 3D modeler, architectural draftsman, aerosol muralist, portraitist, graphic designer, creative consultant and advertising director.