PDA

View Full Version : Logwatch under Fedora 8 too verbose



lhouk
15th April 2008, 08:59 PM
Since upgrading from Fedora 7 to Fedora 8, the unmatched entries in the "Connections (secure-log)" section of my daily logwatch reports have dramatically increased. Most of the entries were generated by sshd, but I've also seen unmatched CROND, unix_chkpwd, and vmware-authd entries. The systems are configured just as they were under the previous Fedora.

Has anyone else experienced this, and does anyone know how I can get the same level of unmatched entries as under Fedora 7? Thanks in advance to all who respond.

RJFUatHOME
16th April 2008, 01:45 AM
The settings for logwatch, at least in fedora 7, are stored in /usr/share/logwatch/default.conf/logwatch.conf.

As root take a look at this file, the section at least on my version is:

# The default detail level for the report.
# This can either be Low, Med, High or a number.
# Low = 0
# Med = 5
# High = 10
Detail = High

I set mine to High, I like all the details. The default for version 7 was Low, maybe they changed it in version 8?

icydog
16th April 2008, 01:57 AM
The number of unmatched entries is due to... the number of unmatched entries. You should probably figure out what's causing those entries. Logwatch generates almost nothing for me on days when not much happens.

Hlingler
16th April 2008, 02:10 AM
Since upgrading from Fedora 7 to Fedora 8, the unmatched entries in the "Connections (secure-log)" section of my daily logwatch reports have dramatically increased. Most of the entries were generated by sshd, but I've also seen unmatched CROND, unix_chkpwd, and vmware-authd entries. The systems are configured just as they were under the previous Fedora.

Has anyone else experienced this, and does anyone know how I can get the same level of unmatched entries as under Fedora 7? Thanks in advance to all who respond.If I saw a huge increase in security log reports referencing "sshd", "unix_chkpwd", and "vmware-authd", I'd be looking for a hacker trying to get in.

Or, you could blissfully ignore the reports, and turn down the verbosity level....

V

lhouk
16th April 2008, 03:31 PM
If I saw a huge increase in security log reports referencing "sshd", "unix_chkpwd", and "vmware-authd", I'd be looking for a hacker trying to get in.

Or, you could blissfully ignore the reports, and turn down the verbosity level....

VOh, I recognize the events being logged. In fact, 80% of them are being generated by my own activities. Not that I'm doing anything different, it's just that none of this stuff was unrecognized under Fedora 7. The minute I started running Fedora 8, I started getting all these unrecognized entries.


The settings for logwatch, at least in fedora 7, are stored in /usr/share/logwatch/default.conf/logwatch.conf.

As root take a look at this file, the section at least on my version is:

# The default detail level for the report.
# This can either be Low, Med, High or a number.
# Low = 0
# Med = 5
# High = 10
Detail = High

I set mine to High, I like all the details. The default for version 7 was Low, maybe they changed it in version 8?I thought of the same thing, but when I checked, the setting was still Low.

For some reason, logwatch isn't recognizing messages that it used to. For example, part of a recent log is attached below (with some data changed for security reasons, naturally):


system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)This is all routine stuff. Why it's unrecognized by logwatch is what I can't figure out.

Hlingler
16th April 2008, 03:39 PM
I wonder if all that new security log activity is being generated by the new PolicyKit stuff? Not sure....

V

lhouk
22nd April 2008, 04:15 PM
(I previously posted this in the Security forum, but since the issue is still unresolved, I thought I would try in a forum with a greater readership.)

Since upgrading from Fedora 7 to Fedora 8, the unmatched entries in the "Connections (secure-log)" section of my daily logwatch reports have dramatically increased. The entries are all routine events that should not be unmatched, as the following log section (with some data changed for security reasons, naturally) shows:


system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Accepted publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Connection from 123.123.123.123 port 12345: 1 Time(s)
system1 sshd[12345]: Found matching RSA key: aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: 2 Time(s)
system1 sshd[12345]: Postponed publickey for lhouk from 123.123.123.123 port 12345 ssh2: 1 Time(s)
system1 sshd[12345]: Closing connection to 123.123.123.123: 1 Time(s)
system1 sshd[12345]: Connection closed by 123.123.123.123: 1 Time(s)The systems are configured just as they were under Fedora 7. I also checked the default detail level for logwatch reports in /usr/share/logwatch/default.conf/logwatch.conf, and it is still set to Low.

Has anyone else experienced this? Does anyone know how I can stop logwatch from reporting entries as unmatched when they shouldn't be, the way it used to under Fedora 7? Thanks in advance to all who respond.

Seve
22nd April 2008, 08:15 PM
( Threads Merged )

Please don't double / cross post

See the FedoraForum.org guidelines (http://www.fedoraforum.org/?view=guide)

Seve

lhouk
23rd April 2008, 05:27 PM
( Threads Merged )

Please don't double / cross post

See the FedoraForum.org guidelines (http://www.fedoraforum.org/?view=guide)

SeveMy apologies. I didn't mean to commit a faux pas. I hope my bad manners won't keep you and everyone else from helping me to solve my problem.

Leslie

Hlingler
23rd April 2008, 06:35 PM
Once again, I suspect that the new PolicyKit thing is responsible for all those new messages. But I'm not sure. You should investigate the PolicyKit documentation the see if it provides any info. Try:
> man PolicyKit
> man PolicyKit.conf <<== This one might be good for settings like log verbosity
Less likely, but part of the documentation suite:
> man polkit-config-file-validate
> man polkit-grant
> man polkit-list-actions
> man polkit-policy-file-validate
> cat /usr/share/doc/PolicyKit-0.6/README|more
> cat /usr/share/doc/PolicyKit-0.6/HACKING

See if any of that helps. If not, may be that something else is generating those messages. But that's as good a place to start as I can think of.

V

lhouk
24th April 2008, 09:04 PM
Once again, I suspect that the new PolicyKit thing is responsible for all those new messages. But I'm not sure. You should investigate the PolicyKit documentation the see if it provides any info. Try:
> man PolicyKit
> man PolicyKit.conf <<== This one might be good for settings like log verbosity
Less likely, but part of the documentation suite:
> man polkit-config-file-validate
> man polkit-grant
> man polkit-list-actions
> man polkit-policy-file-validate
> cat /usr/share/doc/PolicyKit-0.6/README|more
> cat /usr/share/doc/PolicyKit-0.6/HACKING

See if any of that helps. If not, may be that something else is generating those messages. But that's as good a place to start as I can think of.

VHlinger, thanks for the suggestions. While I can't prove that PolicyKit isn't the cause of all the unrecognized messages I'm seeing, I don't see any evidence that it is. My PolicyKit.conf file looks empty:

lhouk@system1$ cat /etc/PolicyKit/PolicyKit.conf
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!-- See the manual page PolicyKit.conf(5) for file format -->

<config version="0.1">
</config>
Likewise, polkit-list-actions shows several entries concerning power management and devices, but not much else:

lhouk@system1$ polkit-list-actions
org.freedesktop.hal.power-management.keyboard-backlight
org.freedesktop.hal.power-management.light-sensor
org.freedesktop.hal.power-management.lcd-panel
org.freedesktop.hal.power-management.cpufreq
org.freedesktop.hal.power-management.hibernate
org.freedesktop.hal.power-management.suspend
org.freedesktop.hal.power-management.set-powersave
org.freedesktop.hal.power-management.reboot-multiple-sessions
org.freedesktop.hal.power-management.reboot
org.freedesktop.hal.power-management.shutdown-multiple-sessions
org.freedesktop.hal.power-management.shutdown
org.freedesktop.hal.killswitch.wlan
org.freedesktop.hal.killswitch.bluetooth
org.pulseaudio.acquire-high-priority
org.pulseaudio.acquire-real-time
org.freedesktop.hal.storage.crypto-setup-removable
org.freedesktop.hal.storage.crypto-setup-fixed
org.freedesktop.hal.storage.eject
org.freedesktop.hal.storage.unmount-others
org.freedesktop.hal.storage.mount-removable
org.freedesktop.hal.storage.mount-fixed
org.freedesktop.hal.device-access.pda
org.freedesktop.hal.lock
org.freedesktop.hal.device-access.ieee1394-avc
org.freedesktop.hal.device-access.ieee1394-iidc
org.freedesktop.hal.device-access.scanner
org.freedesktop.hal.device-access.camera
org.freedesktop.hal.device-access.dvb
org.freedesktop.hal.device-access.cdrom
org.freedesktop.hal.device-access.video4linux
org.freedesktop.hal.device-access.sound
Of course, I might be missing something, given my total unfamiliarity with PolicyKit.

Hlingler
25th April 2008, 12:48 AM
Then read:
man sshd_config

And try setting (as root user) the LogLevel parameter in /etc/ssh/sshd_config to 'error' or 'quiet'. Don't forget to remove the comment symbol (#) from the beginning of the line.

See if that helps.

V

EDIT: Oh, and you'll have to reload/restart the ssh service after making such a config change: service sshd reload or if that chokes: service sshd restart.

lhouk
25th April 2008, 09:08 PM
And try setting (as root user) the LogLevel parameter in /etc/ssh/sshd_config to 'error' or 'quiet'. Don't forget to remove the comment symbol (#) from the beginning of the line.Success! On all the systems we upgraded, the LogLevel parameter was uncommented and set to "Verbose".

Thanks very much for your kind (and patient) assistance!

Leslie

lhouk
6th May 2008, 03:13 PM
One final followup: on one system only, every day I get lots of syslog messages like:
system1 CROND[20002]: pam_keyinit(crond:session): CLOSE 1,123877723,1: 1 Time(s)
system1 CROND[20002]: pam_keyinit(crond:session): REVOKE 123877723: 1 Time(s)
system1 CROND[20002]: pam_keyinit(crond:session): UID:0 [0] GID:0 [0]: 1 Time(s)
system1 CROND[20002]: pam_succeed_if(crond:session): 'service' resolves to 'crond': 1 Time(s)
system1 CROND[20104]: pam_keyinit(crond:session): CLOSE 1,507867822,1: 1 Time(s)
system1 CROND[20104]: pam_keyinit(crond:session): REVOKE 507867822: 1 Time(s)
system1 CROND[20104]: pam_keyinit(crond:session): UID:0 [0] GID:0 [0]: 1 Time(s)
system1 CROND[20104]: pam_succeed_if(crond:session): 'service' resolves to 'crond': 1 Time(s)Am I correct in thinking that I'm just getting these entries everytime the cron daemon runs? Assuming that is the case, is there somewhere in a cron or pam configuration file that I can stop these messages from being logged, as I did for ssh in /etc/ssh/sshd_config? Again, thanks in advance for all responses.

Leslie

Hlingler
6th May 2008, 03:57 PM
It sure looks like there's a cron job scheduled to run fairly often with root privileges on behalf of you or someone(thing) else. Unfortunately, there's no timestamps, but I bet you'd see the five-minute default interval between grant and revoke.

As with the previous sshd issue, stopping this verbose logging should probably be done in the config of the program that runs the job. What if any cron jobs are scheduled to run on this box, but not the others? And what is the purpose/program/command? In KDE, 'kcron' (if you have it) run as root will give you a GUI to sort through to find out who scheduled and "owns" the job. In GNOME, gnome-schedule (run for each user) will do the same. If neither available, then (as root user), search through folder(s) /etc/cron.d/, /etc/cron.daily/, /etc/cron.[etc....]/ to find the file that lists the scheduled job, who owns/starts it, etc. and the program that is to be run. Once you know what program is to be run, you can go into it's config and turn down the verbosity level there.

V

lhouk
8th May 2008, 09:11 PM
It sure looks like there's a cron job scheduled to run fairly often with root privileges on behalf of you or someone(thing) else. Unfortunately, there's no timestamps, but I bet you'd see the five-minute default interval between grant and revoke.Well, I've gone through all the crontab files, and I haven't found anything out of the ordinary. The one interesting thing I've found is in /var/log/secure, where every hour I see the following entries:
May 7 02:01:01 system1 crond[26500]: pam_localuser(crond:account): checking "root:x:0:0:root:/root:/bin/bash#012"
May 7 02:01:01 system1 crond[26500]: pam_keyinit(crond:session): OPEN 1
May 7 02:01:01 system1 crond[26500]: pam_keyinit(crond:session): UID:0 [0] GID:0 [0]
May 7 02:01:01 system1 crond[26500]: pam_keyinit(crond:session): GET SESSION = 1
May 7 02:01:01 system1 crond[26500]: pam_keyinit(crond:session): GET SESSION = 1
May 7 02:01:01 system1 crond[26500]: pam_keyinit(crond:session): JOIN = 385418496
May 7 02:01:01 system1 crond[26500]: pam_limits(crond:session): reading settings from '/etc/security/limits.conf'
May 7 02:01:01 system1 crond[26500]: pam_succeed_if(crond:session): 'service' resolves to 'crond'
May 7 02:01:01 system1 CROND[26500]: pam_keyinit(crond:session): CLOSE 1,385418496,1
May 7 02:01:01 system1 CROND[26500]: pam_keyinit(crond:session): REVOKE 385418496
May 7 02:01:01 system1 CROND[26500]: pam_keyinit(crond:session): UID:0 [0] GID:0 [0]
May 7 02:01:01 system1 CROND[26500]: pam_succeed_if(crond:session): 'service' resolves to 'crond'There's nothing in /etc/cron.hourly to generate this. Do you know of any reason that cron should be invoked every hour?

Leslie

Hlingler
9th May 2008, 12:13 AM
Something about the whole installation/setup on this one machine must be different than the others. I cannot know what that is. I can make some guesses/suggestions: also running other job schedulers (fcron, anacron, atd)? What about xinetd service(s) - any special/different ones enabled? Is WebMin/UserMin installed? They can run scheduled jobs outside of the crond config. What about servers (Web/file/dhcp/httpd/ftpd/etc.)? Antivirus (clamav)? Firewall? Check your root-user's system mail? Running a different desktop (GNOME vs. KDE or XFCE)?

I'm afraid you'll have to hunt this one down - maybe by direct comparison of the crond config files between this machine and at least one other. But regular hourly runs of something at 1:01 past every hour sure look like a cron/fcron/anacron/atd job, and it clearly says: " 'service' resolves to 'crond' ".

V

Hlingler
9th May 2008, 12:35 AM
May 7 02:01:01 system1 crond[26500]: pam_limits(crond:session): reading settings from '/etc/security/limits.conf'HO!HO! Check this out:
[vince@micron-pc-rb Thu May 08 19:31:16 ~]$ cat /etc/security/limits.conf|more
[...]
# End of file

## Automatically appended by jack-audio-connection-kit
@jackuser - rtprio 20
@jackuser - memlock 4194304
[vince@micron-pc-rb Thu May 08 19:31:36 ~]$