Jeff Newmiller <[EMAIL PROTECTED]> writes: > > "Michael D. Schleif" <[EMAIL PROTECTED]> writes: > > > Generally, on a LEAF firewall, if wtmp grows by mB per day, then you > > > have a problem; and, the real problem is not wtmp. > > > > BTW, note that on Bering 1.0-rc3 /var/log/wtmp doesn't exist at bootup, and > > unlike /var/log files under the control of syslog, wtmp won't be written to > > unless it exists. Thus 'last' will just error if you run it. > > wtmp is not under the control of syslog. It is under the control of > login (and sshd). [1]
Yes, I know. As I said, "unlike /var/log files under the control of syslog...". > login is implemented in Bering with tinylogin, and depending on the > compile option, tinylogin may or may not maintain lastlog/utmp/wtmp. Given > the problems with "last" that have been pointed out, I would guess this > compile option is not selected. > > Some compiles of sshd have inadvertently left support for lastlog in, but > there isn't much point if login isn't supporting it also. On Bering 1.0-rc3, /var/log/wtmp is successfully updated by both console logins and sshd logins, once you 'touch' it. > > The solution is to put 'touch /var/log/wtmp' in one of the startup scripts. > > On my systems I put that in the 'start' section of /etc/init.d/sysklogd, > > since that's the point at which the other /var/log files get created. In > > his response to my bug report, Jacques stated that in the next version of > > Bering, /etc/init.d/rcS will contain the command somewhere. > > I recall that lastlog has been a pain in the past, because it is arranged > as an "array" indexed by UID, yielding large blanks in utmp between > unassigned UIDs. Well, we weren't talking about utmp, just wtmp. > These blanks appeared not to be "holes", so actual ramdisk space was > squandered in them. It would seem that using nonstandard UIDs would solve > this problem, but the typical solution has been to omit lastlog processing > entirely. Bering includes log cycling for wtmp, so if there is some kind of space wastage issue (not sure if you're saying this occurs in wtmp as well, or just utmp), that should mitigate the problem. > If wtmp is not present, then last is pointless. > > So what really needs to be fixed? All that needs to be fixed is for one of the startup scritps to 'touch /var/log/wtmp', so it'll be written to. As I said, Jacques has already responded to my bug report saying that this will be done in the next version of Bering, so I don't know how much debate this issue warrants. > One might argue that it would be nice to see who had logged in recently, > but that will almost certainly be "root". Some people set up additional users, say, to allow someone to log in and add DNS info, but not be able to have full control of the machine. > Knowing when root logged in would be nice, Unfortunately that's the one piece of data the LEAF version of last doesn't print, which is odd. The only time info is how many minutes the account was logged in for. The information _is_ being logged, though, because scp'ing the wtmp file to a full Linux host and running 'last' there shows the login times. Hopefully someone will eventually get the time to upgrade /lib/POSIXness/POSIXness.system (note I erroneously assumed Bering's 'last' was provided by BusyBox in my bug report) to show the login times. In any case, LEAF's last does tell you what remote machine people logged into the sshd from, which is potentially very useful info. > but "fixing" lastlog/wtmp is a standard intrusion action and would most > likely be the first thing an unauthorized root user would do. If they're a skilled hacker and have brought with them a rootkit that works on LEAF, perhaps, but otherwise, no. Most script kiddies will probably leave the file alone, or without the ability to edit the binary file, they may just zero it, which will also tell you that someone's broken in, if you're paying attention. > So we would be deluding ourselves if we thought wtmp was a security > measure in LEAF. It *is* a security measure -- it just isn't a foolproof one (and what security measure truly is?). Another thing is that people who have their LEAF box set up to log to a remote loghost may also have something in place to transfer the wtmp file to the loghost. I've been thinking about setting up a program to continually watch wtmp, and upload it whenever it changes (keeping a certain number of backup copies on the loghost so you can detect changes, and/or watch for changes with a non-standard size delta). With such a program in place, it's likely you'd almost always be able to upload the wtmp prior to a hacker being able to transfer their (appropriately set-up) rootkit onto the LEAF box, unpack it, and use it. > In the interest of not providing false hope, and in minimizing filesystem > and disk usage, I lean toward the "remove last" rather than the "support > wtmp" option. False hope? wtmp is already supported... Please don't remove last. If someone doesn't want /var/log/wtmp, they'll merely have to comment out the 'touch' line, once that's added. Personally, I want it. --------------------------------------------------------------- Dan Harkless | To prevent spam contamination, please [EMAIL PROTECTED] | do not post this private email address Unitech Research, Inc. | to the USENET or WWW. Thank you. ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
