If you are using Solaris 10, and you have not used bart yet, you should stop everything and take a look at it.

For those who don’t know what bart is, it is the Basic Auditing and Reporting Tool that is in Solaris 10.

In a quick synopsis bart will create a report that shows all files/directories on a solaris machine. This report contains the permissions, owners, sizes, modify times and md5 hashes of all files on the system, along with acl’s if you are using ZFS.

So why is bart so important? First, it can be used as a security tool. When you install a new Solaris 10 system, the first thing you should do after you get it installed and patched and before it is placed on the network is run a bart on the system and save the report to a cd. This will be the “baseline” image of the system. Then every week/month you should run a bart against the machine again and then use the compare option to see what files have changed, added or deleted from the system. Where this comes in really handy is if your think that your machine has been hacked or compromised. You can use the comparison to determine which files may have been modified by the hacker.

But there is a non-security use for bart as well that is VERY useful. This use is one that I had not thought of until I needed it the other day. So what is this use? Reseting the permissions on files that were accidentally changed by an in-experienced UNIX person thinking that a “chmod -R 777 *” is the best way to fix their problems.

The first thing that came to my mind when I saw this happen was oh no, the machine had not even been backed up yet, and a day’s worth of work would have been lost. Even if the machine had been backed up, do you realize how long it would take to restore a file system with 40,000+ files, just because the permissions were screwed up. ( Note, the permissions on the various files were very different and even included some setuid, and setgiud files which were wiped out as well.)

So how did bart save the day? Luckly I had taken a bart of the machine before the work had begun on the file system. So after the chmod command was issued, I then took a bart of the file system again. I now could run a bart compare against the control and test manifest and see exactly what all had changed.

Once I had this output, I could then create a script to change the permissions of the files/directories back to the original values. All told after I finished tweaking my script it took about 20 minutes to reset the permissions on all the files and directories.

So here is a quick start to getting your first bart manifest of your system:

1. Create a bart_rules file. If you do not create a rules file, your output will only have Files and not directories listed in it. My simple bart_rules file looks like this:

/
CHECK ALL
/home
IGNORE ALL

I ignore the /home file system as in my case it was nfs mounted. In reality you would want to include all local file systems.

2. Create the bart, I keep the rules file in /root/bart_rules so I would run the command:

bart create -R / -r /root/bart_rules > /tmp/bart.output

This will create a bart manifest and output it to /tmp/bart.output. Looking at the first couple of lines of it looks like this:

unixwiz@sungeek:/home/unixwiz> head -20 /tmp/bart.out
! Version 1.0
! Saturday, May 17, 2008 (21:24:27)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 1024 40755 user::rwx,group::r-x,mask:r-x,other:r-x 481d0e43 0 0
/.ICEauthority F 310 100600 user::rw-,group::—,mask:—,other:— 44c581c2 0 0 3eb63faf448e8a2b2c1a7b2019a8bde3
/.Xauthority F 99 100600 user::rw-,group::—,mask:—,other:— 44c560e0 0 0 5ffe2e5f4b6f73e662001f62f7cae4d3
/.bash_history F 649 100600 user::rw-,group::—,mask:—,other:— 481d1109 0 0 9132e0e798d5d05644cafc90c2aa876a
/.dt D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 44c560e0 0 0
/.dt/appmanager D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 44c5534d 0 0
/.dt/help D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 44c5534d 0 0
/.dt/icons D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 44c5534d 0 0
/.dt/sessionlogs D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 44c5534c 0 0
/.dt/sessionlogs/sungeek_DISPLAY=:0 F 132 100644 user::rw-,group::r–,mask:r–,other:r– 44c560e0 0 0 6d4e62fc972046a7a85fdb36a0ce21fd

The first part of the file, the part that begins with #fname is a legend as to how each type of line is formed.
So looking at the first actual line of the contents :

/ D 1024 40755 user::rwx,group::r-x,mask:r-x,other:r-x 481d0e43 0 0

We see that the fnmae is /, it is a directory, with a size of 1024. Its mode is 755, the last modified time is the “481d0e43″ and it is owned by uid 0 and gid 0.

Looking at a file in particular we see this:

/httpd/htdocs/index.html F 10 100644 user::rw-,group::r–,mask:r–,other:r– 463d4f4b 0 0 b7a9369d4cc9f82ed707bce91ced8af8

In the above, we see that the file is 10 bytes, has a permissions of 644 and is owned by root/root.

Now suppose that I for some reason by accident was in the /httpd/htdocs directory and did a chmod -R 777 *. Since I had my control manifest, I would then run another bart and then use the compare option. What I would get is something like this:

#bart compare /tmp/bart.output /tmp/bart.output2
/httpd/htdocs/index.html:
  mode  control:100644  test:100777
  acl  control:user::rw-,group::r–,mask:r–,other:r–  test:user::rwx,group::rwx,mask:rwx,other:rwx

Here we can see that the permissions has changed from 644 to 777. But the output is not really easy to parse with a script. So we need to use the “-p” option on the bart compare:

#bart compare -p /tmp/bart.output /tmp/bart.output2
/httpd/htdocs/index.html mode 100644 100777 acl user::rw-,group::r–,mask:r–,other:r– user::rwx,group::rwx,mask:rwx,other:rwx

In the above, since the only thing that was changed was the mode, that is the only thing that is listed.

here are some other examples:

/var/samba/locks/browse.dat mtime 482f8544 482f8800
/var/samba/locks/unexpected.tdb contents 7c3404e9622749702e3df56caf26fe72 72983947ada3260a236394a51aef0d31

The first line shows that the file browse.dat modify time changed, but nothing else. The second line shows that the unexpected.tdb had it’s contents change. This can been see by the 2 different hashes.

Here is another example of the index.html file above, after it had been edited:

bash-3.00# bart compare /tmp/bart.out /tmp/bart.out3
/httpd/htdocs/index.html:
  size  control:10  test:26
  mode  control:100644  test:100777
  acl  control:user::rw-,group::r–,mask:r–,other:r–  test:user::rwx,group::rwx,mask:rwx,other:rwx
  mtime  control:463d4f4b  test:482f8b89
  contents  control:b7a9369d4cc9f82ed707bce91ced8af8  test:1567caf683e3859cb5da7335c35438f7

Once again this is in the “human” readable format, the “machine” readable looks like :

bash-3.00# bart compare -p /tmp/bart.out /tmp/bart.out3
/httpd/htdocs/index.html size 10 26 mode 100644 100777 acl user::rw-,group::r–,mask:r–,other:r– user::rwx,group::rwx,mask:rwx,other:rwx mtime 463d4f4b 482f8b89 contents b7a9369d4cc9f82ed707bce91ced8af8 1567caf683e3859cb5da7335c35438f7

(the above is actually all on one line.)

Once you have the output of the bart after the “oops” you will need to run the bart compare with options to ignore some items. Since I am only interested in the mode, the size, mtime and contents can be ignored. I used the following:

bash-3.00# bart compare -i size,mtime,contents,uid,gid -p /tmp/bart.out /tmp/bart.out2

This only shows files that have had their mode changed:

bash-3.00# bart compare -i size,mtime,contents,uid,gid -p /tmp/bart.out /tmp/bart.out2
/httpd/htdocs/index.html mode 100644 100777 acl user::rw-,group::r–,mask:r–,other:r– user::rwx,group::rwx,mask:rwx,other:rwx

You should redirect this output to a file, so that it can then be used to generate a script.
With the output in a file I then did this:

cat /tmp/bart.compare | awk ‘{print "chmod "$3" "$1}’ > /tmp/CHANGEPERMS

So basicly I cat the file and print the chmod command allong with the 3rd field (100644) and then the first field (/httpd/htdocs/index.html) and redirect this to a new file. Once I spot check this file, you can then run it and it will “reset” the permissions back.

Now everything I have shown above is based on the machine having a UFS file system. If you run bart against a file system that is ZFS, you will get a manifest that looks something like this:

/home/unixwiz/bin/php F 10587732 100755 owner@::deny,owner@:read_data/write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:allow,group@:write_data/append_data:deny,group@:read_data/execute:allow,everyone@:write_data/append_data/write_xattr/write_attributes/write_acl/write_owner:deny,everyone@:read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4743a7fa 100 14 9b8cfb15ed069bd6e43d7c2ae11a3e23

It shows the ZFS extended acl’s.

So if you haven’t started using bart, you should start as soon as possible.

Posted by unixwiz, filed under Security, Shell Scripts, Solaris, ZFS, tips. Date: May 17, 2008, 10:25 pm | Comments Off

Well it seems that yet another “tape” has been lost with peoples data on it.. GE Money is now reporting that 650,000 store credit card users could have their information in the hands of some one else. This seems to be a common quote now adays:

Getting data off the tape would be a chore for thieves according to Iron Mountain, although it said it regretting misplacing the tape. “We occasionally make mistakes,” a spokesperson told the Associated Press.

Why do they always think that it is going to be such a ‘chore’ for thieves to get data off of the tapes. I can almost bet that most people are NOT encrypting their data before it gets put on tape.

Posted by unixwiz, filed under Interesting, Random Stuff, Security. Date: January 18, 2008, 11:04 pm | Comments Off

Today I needed to see what patches were missing on a ton of machines. Instead of trying to start the Patch manager of the month for solaris, I wrote this little script that would produce me a HTML page of the current patches installed and ones that needed to be installed. This script is based off of the patchdiag.xref available from Sun. I know there are many other tools out there such as PCA (Patch check advanced) but in the environment I was in today, I could not use any third party programs so I wrote my own. The output looks like this:

output of patch checking script

What the script does is the following:

  1. Get a list of current patches on the machine
  2. Find the latest version of each patch that is installed on the machine and compare it to the latest version available according to the patchdiag.xref
  3. Generate one line of HTML code, listing the patch, the current installed revision and the current available revision and a description of the patch. It will also place a link to the patch on sunsolve.
  4. At the end it will list a summary of patches installed, missing, obsolete, and how many security and recommended patches there are.
  5. It will then compare the list of currently available patches against what is installed to see if there are patches that are available but not installed on the system
  6. If a patch has never been installed it will then list the line of HTML code showing the patch number, revision, flag (security,recommended) and its description
  7. At the end it will display the total number of patches that are not installed and how many are recommended and/or security

Basically it is a very simple script. It should work on all versions of solaris from 7+. It ONLY looks at Solaris specific patches and not those that are unbundled (i.e. Sun Studio, Web Server, etc.)

Here is the script, it may not be the cleanest or most efficient, but it was a quick job…

Shell script to analyze solaris patches

Posted by unixwiz, filed under Security, Shell Scripts, Solaris. Date: January 18, 2008, 10:02 pm | Comments Off

It is nice to be notified that your personal information has been lost by UPS. I got a letter the other day from my prior health insurance agency for my prior job. It seems that a “data tape” containing over 200,000 current and prior peoples information has been lost by UPS during transit to a “data analyst”. Some quotes from the letter they sent:

A mainframe computer tape containing your and your dependents’ name, address and social security number was reported as lost by United Parcel Service while in route to XXXXX’s data anaylst.

So what makes a “mainframe computer tape” different from any other computer tape. Nothing just trying to “sound” big and important to the people they are now having to tell that they screwed up.

Every effort possible is being made to recover the missing data tape. The tape is of a type which cannot be read using a personal computer (PC). The tape is only accessible using highly specialized and expensive equipment, usually only possessed by large, sophisticated business entities.

Now the last time I looked a tape is a tape is a tape. It does not matter if you are using a PC or a Mainframe or a Sun box. As long as you have the hardware to physically read the tape then it can be read. Whether you can get data off of it is another thing. I like the second set of buzz words they use too: “only accessible using highly specialized…. usually only possessed by large, sophisticated business entities.”

You can tell they are trying to “calm” the people down to make it seem like it is not as a big of a deal that you would think it is. Funny thing is that if the “person” who has the tape really wanted to read it all they need to do is look at ebay.. I can find a “mainframe” tape drive on there for about $700.

Now here is hoping that the data on the tape is actually encrypted, but I bet it is not because most people don’t even bother encrypting the data they put on tapes… Not that it is hard to do with either software or hardware, they just don’t think they will ever have a problem with “losing” a tape till one is lost.

Any way enough with this rant. Guess it is time to go look and see if any one has actually started to use the data.

Posted by unixwiz, filed under Rant, Security. Date: October 27, 2007, 10:24 pm | Comments Off

After reading ThinGuy’s Blog: Are PC’s Killing Health Care? I can’t agree more… It got me to thinking when I was in the emergency room of a local hospital last summer. (Long story, but spent a while there) Anyways, while I was there (I have not been to the ER in ages and the last time I was everything was still done on paper), they popped down a little thing on the wall and he behind it was a “Windows Thin client”. The nurse did nothing but b@#*h about how slow it was. I watched and it looked to be running a Wyse Client and using Windows from some place that was not local. I got to thinking about how a Sun Ray environment would work in this hospital. Here are some ideas I thought of while laying in that short bed (I am over 6′5″) for 5 hours.

  1. Instead of having the paper charts, when you arrive, your are “assigned” a smart card and all your information follows you on that card no matter where you go (AKA HCHD, Hospital Chart Hot Desking). For example I had to end up going to X-Ray, and the X-Ray tech did not have the complete orders and started taking Chest X-Ray’s instead of X-Ray’s of my knee. (Later found out that they wanted both, but the doctor forgot to put the knee one on the order sheet, if he had seen my chart he would have known that the original reason I was there was for knee problems).
  2. The monitoring devices in the room (BP/Heart Rate/oxygen/etc) could be attached to the Sun Ray and therefore your info logged and displayed on the Sun Ray at a click of the button.
  3. Each patient could be given their own card for surfing the web, etc.. (if they are ambulatory enough to do this)
  4. By using the smart card to keep track of your stats, there is no paper to accidentally get “lost” or stolen (helps with HIPPA).
  5. Be a lot faster than the current Wyse Terminals they were using as they would not have to wait for it to boot.
  6. Security, there isn’t a day go by that I don’t read about some one losing some one else’s information. I.E. VA Hospital, (which uses some Sun Rays in areas around where I am), This would eliminate all of these loses, if everyone was forced to use it.
  7. All Labs/X-Rays posted directly to the persons “card”

Granted some of the above would be a feat to pull off, but it can be done.

I think that using Sun Ray’s is the coolest thing, especially now that I have it set up for all the people in my group to pull their card out of their Office Sun Ray and plug it in to their Home Sun Ray and everything is still there. (If I can just get the performance problems worked out it would be really killer, but something about the combination of Solaris 10, Sun Ray 4 is causing me some slowness, and I am not sure where it is exactly. )

Now if more people realize the benefits of using Sun Ray’s over other “Chubby Clients” Sun Ray’s would take over the world.

Posted by unixwiz, filed under Interesting, Security, Sun, Sun Ray, Sun Ray @Home. Date: November 6, 2006, 10:42 pm | No Comments »

« Previous Entries