Debian logcheck settings (2nd.)

STATUS: Frozen (2019-11-17)

No more updates for this guide.

Please refer to the TOC page.

Rev 3

Minor tweaks.

Both desktop workstation and local low load server, log management is important.

  1. logcheck gives us summary reports via local mail.
  2. System groups adm and systemd-journal allow us to read raw logs.

tier1.jp recommends logcheck.

Install MTA. MUA and logcheck

root# apt install logcheck mutt
root# mount -o remount rw / # don't forget; we keep rw in this section.
root# dpkg-reconfigure exim4-config # make sure the MTA settings.


Exim4 has severe vulnerabilities. Make sure you update it.

It is good to have a AppArmor enforce profile for it, not to allow extra code executions.

In most cases MTA setting is local delivery only.

If you want something centralized log managements, consider introducing dedicated syslog server first.

Logcheck configuration to minimize reports

By default, logcheck produces a lot of system event logs. To reduce that, change the report level.

Debian stretch also installs logcheck-database with logcheck itself.

root# nano /etc/logcheck/logcheck.conf
REPORTLEVEL = "workstation"

Or, write your own local- ignore rules, putting them in /etc/logcheck/ignore.d.workstation, for example.

logcheck ignore database

tier1.jp provides some of it under GNU GPLv2.

If you are interested, see logcheck ignore rule page in this site.

Logcheck mail recipient

Confirm who would receive the logcheck mail.

We did not create a normal user during Debian installation. In this case root will receive the summary mails.

Add a user to receive summary mails, then change the recipient user.

root# nano /etc/aliases

If you want to change which user(s) should receive, edit that section.

If you use Mozilla Thunderbird, Account Setting => Account Actions => Add other account.

tier1.jp recommends mutt for those local mails.


Summary mails "System Event" section logs are not so important.

Just watch auth fail logs, external device related. something like that.

Just reading "Security Events" would help.

Considering User Hierarchy

This is something off topic.

Let us consider user hierarchy once.


This is not something "standard" nor "de-fact standard".

User Class What can do / cannot do / should not do
Normal User Daily routine only. No admin tasks. Least sys groups.
Super User su or sudo or some special system group tasks.
root Can do everything, but should do least.

Consider a normal user "bob". It does daily routines. It has no adm sysgroup, no su capability (no wheel), and of course no sudoer.

Why? Because normal users are most likely risky.

  1. They use browsers, USB devices. Risk of malware infections.
  2. They use GUI feature rich MUA, etc. Risk of extra threats.
  3. They are many, and people make mistakes.

So, let us limit those risk, with limiting user authorities.

Separating risk

In Debian GNU/Linux, we can freely add extra users.

  1. Choose some normal users as trusted users; say "alice" and "bob".
    • both "alice" and "bob" left as they are.
    • People behind "alice" and "bob" are trusted; not UNIX users.
  2. Create trusted user accounts for "trusted people" above.
    • say, "alice-adm" (who in adm group) and "bob-apt" (who can sudo apt) unix accounts.
    • They have (ideally) completely or partially different passwords.
    • They are not used daily; used on demands, by SAME people.

This approach makes root task reduced, with exposing minimal risk.

published: MODIFIED: