What's this log entry mean? (FreeBSD)

Hello,

I inherited a virtual FreeBSD server that is currently quietly serving static webpages as it's main occupation.
I ssh in as root on occasion and perform Apache stuff, update OpenSSL etc and I read the status mail that has accumulated and it's always the same except recently twice in a row there were entries like this on the weekly security report.

Other than occasional ftp all access is via ssh - no one really has any reasson to access this box from inside the company yet and there have been no resfused login attempts logged or any other sign of anyone sniffing.

Is this a sign of something I should be looking at? SetUID doesn't strike me right off as a security threat - but anything involving root files makes me wonder. It doesn't seem that the files themselves have been replaced or tampered with - just this alert.

TIA - tkk

=== security email audit transcript follows ===

Checking setuid files and devices:


nst.com setuid diffs:
1,11c1,11
< 7775 -r-xr-sr-x 1 0 operator 59388 Sep 18 10:25:35 2001 /bin/dfree
< 7764 -r-sr-xr-x 1 0 wheel 319688 Sep 18 10:33:25 2001 /bin/rcp
< 69736 -r-sr-xr-x 1 0 wheel 198340 Sep 18 10:27:45 2001 /sbin/ping
< 69739 -r-sr-xr-x 1 0 wheel 195800 Sep 18 10:27:46 2001 /sbin/route
< 93035 -r-sr-xr-x 4 0 wheel 19652 Sep 18 10:29:09 2001 /usr/bin/at
< 93035 -r-sr-xr-x 4 0 wheel 19652 Sep 18 10:29:09 2001 /usr/bin/atq
< 93035 -r-sr-xr-x 4 0 wheel 19652 Sep 18 10:29:09 2001 /usr/bin/atrm
< 93035 -r-sr-xr-x 4 0 wheel 19652 Sep 18 10:29:09 2001 /usr/bin/batch
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chfn
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chpass
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chsh
---
> 7775 -r-xr-sr-x 1 root operator 59388 Sep 18 10:25:35 2001 /bin/dfree
> 7764 -r-sr-xr-x 1 root wheel 319688 Sep 18 10:33:25 2001 /bin/rcp
> 69736 -r-sr-xr-x 1 root wheel 198340 Sep 18 10:27:45 2001 /sbin/ping
> 69739 -r-sr-xr-x 1 root wheel 195800 Sep 18 10:27:46 2001 /sbin/route
> 93035 -r-sr-xr-x 4 root wheel 19652 Sep 18 10:29:09 2001 /usr/bin/at
> 93035 -r-sr-xr-x 4 root wheel 19652 Sep 18 10:29:09 2001 /usr/bin/atq
> 93035 -r-sr-xr-x 4 root wheel 19652 Sep 18 10:29:09 2001 /usr/bin/atrm
> 93035 -r-sr-xr-x 4 root wheel 19652 Sep 18 10:29:09 2001 /usr/bin/batch
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chfn
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chpas
s
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/chsh
13c13
< 92930 -r-sr-sr-x 1 66 dialer 123968 Sep 18 10:26:00 2001 /usr/bin/cu
---
> 92930 -r-sr-sr-x 1 uucp dialer 123968 Sep 18 10:26:00 2001 /usr/bin/cu
24c24
< 92989 -r-sr-xr-x 1 9 wheel 28592 Sep 18 10:26:31 2001 /usr/bin/man
---
> 92989 -r-sr-xr-x 1 man wheel 28592 Sep 18 10:26:31 2001 /usr/bin/man
33,36c33,36
< 92931 -r-sr-xr-x 1 66 wheel 88304 Sep 18 10:26:01 2001 /usr/bin/uucp
< 92933 -r-sr-xr-x 1 66 wheel 37372 Sep 18 10:26:01 2001 /usr/bin/uuname
< 92936 -r-sr-sr-x 1 66 dialer 96780 Sep 18 10:26:01 2001 /usr/bin/uustat
< 92938 -r-sr-xr-x 1 66 wheel 88952 Sep 18 10:26:02 2001 /usr/bin/uux
---
> 92931 -r-sr-xr-x 1 uucp wheel 88304 Sep 18 10:26:01 2001 /usr/bin/uucp
> 92933 -r-sr-xr-x 1 uucp wheel 37372 Sep 18 10:26:01 2001 /usr/bin/uunam
e
> 92936 -r-sr-sr-x 1 uucp dialer 96780 Sep 18 10:26:01 2001 /usr/bin/uusta
t
> 92938 -r-sr-xr-x 1 uucp wheel 88952 Sep 18 10:26:02 2001 /usr/bin/uux
40,42c40,42
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchfn
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchpas
s
< 93048 -r-sr-xr-x 6 0 wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchsh
---
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchf
n
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchp
***
> 93048 -r-sr-xr-x 6 root wheel 32324 Sep 18 10:29:15 2001 /usr/bin/ypchs
h

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:

nst.com login failures:

nst.com refused connections:

That is just a daily setuid check if you don't like it you can disable it by adding
daily_status_security_chksetuid_enable="NO" to /etc/periodic.conf but I don't recommend doing so. Instead, you can have the output piped to a log file rather than emailing you (root) daily. Add daily_status_security_output="/var/log/secure_log" to /etc/periodic.conf.

BTW this is FreeBSD specific, therefore, you should post such message ONLY to BSD forum instead, definitely NOT HERE.

Thanks for the reply - I'm aware of the security check procedure - although I hadn't thought of sending it to a log.

I guess I wasn't clear enough - my question was about the contents of the report itself not the method of the reporting.

I was really wondering if the setuid warnings constituted a possible security problem or were signs of a possible intrusion. This would seem to be a pretty generic *nix security question even though it happened on a FreeBSD machine as permissions are Unixversial.

Does this seem like something worth pursuing if there are no other indications of strange activity? Is there a common or obvious exploit that could exist from changing setuid of the commands listed? Obviously replacing a function in /bin or /sbin with a new one could lead to the insertion of ANY code but does this look like a possible problem?

There the security log report was the same for weeks and suddenly two days in a row I received this warning and nothing since. I doubted that it was a problem I didn't just want to ignore it - that would negate the purpose of the security checks in the first place.

TIA,

=tkk

>> if the setuid warnings constituted a possible security problem

Yes as setuid files are the critical ones you'd want to monitor daily for any odd changes.
As far as the common local exploits you can search google to find out more.

It would appear that sometime between runs of this script your passwd database was either corrupted, inaccessible, or tampered with. The first time the script ran, there were no mappings for UIDs --> usernames (note the numbers in the username column). The second time the script ran (the next day), the username mappings were intact.

This doesn't necessarily mean the box was tampered with. However, I'd check the date the script ran, then check all the other logs for any kind of suspicious activity from the day or two before until now. Just to be safe.

There isn't any reason that I can think of that the passwd file would not be readable for even a second. There probably are legitimate reasons, I just can't think of any off-hand.

Good luck.