Package: logcheck Severity: normal I was rolling out a server in a high-security environment, using logcheck (monitoring auth.log) as part of the infrastructure for alerting staff about malicious activity.
I was injecting syslog entries with logger(1), to test my custom logcheck ignore rules, and it occurred to me that a user could do this (where "ERROR" matches a pattern in violation.d): yes ERROR | logger which causes logger to spam syslog with messages. Testing shows that this adds entries faster than logcheck can scan them, preventing the logcheck job from ever completing. An attacker could use this technique to indefinitely delay notification of their attack (say, a dictionary attack on a password-protected service). Admittedly, subsequent jobs will create error mail along the lines of "couldn't get lock", but this sounds like a low-priority error. Currently I'm just advising staff to treat logcheck lockfile mails as high priority, but I figured I should mention it in case there's some technique that logcheck could (or does, but I don't know about) support to mitigate this. PS: by default syslog and syslog-ng accept log entries from local users, but they can be configured to accept entries from remote hosts (making this potentially a remote attack). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]