Hey there,
Today's subject matter hearkens back to a post we did in 2007 about looking around inside Solaris' wtmpx. In that post, the ultimate objective was to get the "year" information, since commands like "last" don't include that information in their output and the lack of that year information can make for confusing output if you don't roll your wtmpx file every year.
Once I stumbled over this command (which is one thing that always amazes me, since I've been using Solaris since 2.4 - there's always something new to learn, even if it's old ;) I was extremely pleased. Of course, knowing how to crack open wtmpx and get at anything and everything inside it is probably a more powerful skill to possess, but, if you're a simplest-is-best kind of guy like me, using a command that will allow you to get the last output with the year attached is perfect if you're looking to get your last output with the year attached. Seems almost self-evident ;)
The command you can use is called "fwtmp" and exists in the "/usr/lib/acct" directory on Solaris and in many and varying places depending on your Linux distro (assuming your db is updated, commands like locate or slocate should make it easy to find). The command has actually been around since Solaris 7, but (yes, I did some research on it when I realized I'd never realized it existed before ;) had some issues that made it unacceptable. Those same issues persisted through most of Solaris 8, but were eventually ironed out by the time Solaris 9 came out (which is also like saying "By the time you had your Solaris 8 system patched to the gills," since a fully patched 64-bit installation of Solaris 8 was, basically, Solaris 9). The command still stands in good stead on Solaris 10 and is working well on every Linux distro I've been able to test.
Even better still, the command's application is extremely simple; allowing you to use its output for whatever diabolical purposes you have in mind (I believe it supports altruism as well ;) Many of the wtmp/btmp implementations on Linux already have a way around this by allowing you to specify time frames (with the -t flag) when you invoke last. Most distro's also include this command (and its fellow commands) by default, as well. This old post on getting the year from last on Linux also demonstrates how Linux makes this whole process less convoluted by allowing you to get the same information from the lastlog file.
For a quick example of how easy this command is to use, check out the following command line session. First we create a temporary file using fwtmp and then we read a line from it to verify that it worked correctly (it doesn't get much simpler than that... unless they just start including the year in last's output ;) :host # /usr/lib/acct/fwtmp < /var/adm/wtmpx > tmp_wtmpx_file
host # head -1 tmp_wtmpx_file
user123 sshd 1258 7 0000 0000 1226072918 230489 0 29 host123.desktop.ourhost.com Fri Nov 7 09:48:38 2008
Simplicity at its finest. There's actually a whole separate binary to fix wtmpx, which basically takes care of cleaning operations you could do yourself.
As a for instance, assuming you had the privileges to do so, and wanted to remove that login listed above from the wtmpx file, you could run that initial command to create the tmp_wtmpx_file, delete that line in it (using vi, emacs, what-have-you) and then convert the text file you got from fwtmp back into a binary wtmpx file, using the same command (The -ic options instruct fwtmp that its input is in ASCII format and needs to be converted to binary):host # /usr/lib/acct/fwtmp -ic tmp_wtmpx_file > /var/adm/wtmpx
Of course, this is a simplistic look at how to do something like that (and certainly not a recommendation to mess with your security logs). You should probably back up files before overwriting them, etc. Still, it's kind of cool to know you can get all this information from wtmpx without having to learn the Perl pack signature (or know anything about C :)
The programming possibilities are only limited to what you need to do and the information fwtmp can provide!
Cheers!
, Mike
Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.
