Rev 3
Minor tweaks.
Both desktop workstation and local low load server, log management is important.
- logcheck gives us summary reports via local mail.
- 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.
Warning
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# adduser LOGCHECK_SUMMARY_USER
root# nano /etc/aliases
root: LOGCHECK_SUMMARY_USER
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.
Note
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.
Warning
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.
- They use browsers, USB devices. Risk of malware infections.
- They use GUI feature rich MUA, etc. Risk of extra threats.
- 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.
- 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.
- 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.