Debian Package of the Day (static archived copy)

fcheck is a program that emails an alert when important files or directories change. This is useful for change control or detecting unauthorized modifications that may indicate an intrusion.

Most sysadmins will agree that having a file integrity checker is a good idea, the problem with them is that they are usually a giant pain to get working and keep up-to-date. Thus they are perpetually on the “to do” list and then you don’t have it when you need it. (Hint, after the intrusion is too late.)

Enter fcheck, which Just Works out-of-the-box with the exception of the “major gotcha” detailed below, and with only a little care and feeding.

When installed it creates the file database (DB) then runs from cron every two hours. When it sees a change it sends email (via cron) then rebuilds the DB by itself, so you won’t get the same error next time. That’s a potential security issue, since if you lose that email you’ve missed your one and only alert. Also, if some files change all the time (like /etc/mtab, /etc/printcap, and /etc/samba/smbpasswd) you will get alerted on them every run, until you go exclude them. The configuration file supports file includes, so keeping a custom fcheck.local file is a breeze.

You will get a large alert message after an aptitude *-upgrade command, which is a great way to validate your change control policy (yup, stuff was changed when it was supposed to; or Who the heck is messing with my server?!?).

The existing package does not include logcheck ignore files, so if you’re using the logcheck package (and you should be on a server) you’ll get a alerts about DB rebuilds unless you add an ignore line (see samples).

The default config file is not bad, and adding new files and directories for fcheck to monitor is really easy, though including directories is a bit subtle in that they are only checked recursively if listed with a trailing ‘/’. See the examples below for things I usually add.

There is also a major gotcha reported in this bug report. It turns out there is a missing exclude needed for /lib/udev/devices/ so the install will hang at “Building fcheck database (may be some time)…” or during a check at “PROGRESS: validating integrity of /lib/” and leave a ton of fcheck processes clogging up your system. See the bug and the samples below for the fix.

Because of the easy failure mode of a single email before the DB update, and the lack of cryptographic protection of its component files, it’s not the most secure program in the book. But it is drop-dead easier than anything else I looked at. In my book, “easy and used” beats “such a pain I never got around to it” any day :-). And it’s not that hard to make it more secure by keeping off-line copies of the DB, configuration and Perl script and adjusting the cronjob to NOT rebuild after changes, if you want to.

If you run a server you should be using fcheck and logcheck. And probably tmpreaper, etckeeper and maybe monit too. To summarise:

Pros:

• Just Works out-of-the box, unlike its competitors
• Simple to set up and use
• Very stable code (hasn’t changed since 2001 or so)
• Written in Perl, for easy hacking
• Runs on Windows too

Cons:

• Arguably not as secure as some competitors
• BUG: https://bugs.launchpad.net/ubuntu/+source/fcheck/+bug/47408
• Package should include an fcheck.cfg that is a bit more comprehensive
• Package should include logcheck ignore files

Other alternatives:

debsums

Verify installed package files against MD5 checksums.

integrit

A file integrity verification program.

osiris

network-wide system integrity monitor control interface.

samhain

Data integrity and host intrusion alert system.

stealth

A stealthy File Integrity Checker.

tripwire

file and directory integrity checker.

Availability:

Debian: Since at least Etch: 2.7.59-8

Ubuntu: Since at least Dapper: 2.7.59-8

Samples:

Edit /etc/fcheck/fcheck.cfg and add at the bottom:

       # Tweak the main file if needed, then add this near the bottom.
       # In addition to the defaults in this main file, also:

       CFInclude       = /etc/fcheck/fcheck.cfg.local

Create /etc/fcheck/fcheck.cfg.local

       # In addition to the defaults in '/etc/fcheck/fcheck.cfg':

       # Track changes to crontabs (may want to limit to some users on busy systems)
       # Note trailing '/' for recursive check of this directory
       Directory       = /var/spool/cron/

       # This stuff changes too often
       Exclusion      = /etc/package.list
       Exclusion      = /etc/printcap
       Exclusion      = /etc/motd
       Exclusion      = /etc/mtab
       #Exclusion      = /etc/samba/smbpasswd
       # for DHCP: Exclusion      = /etc/resolv.conf

       # BUGFIX, per https://bugs.launchpad.net/ubuntu/+source/fcheck/+bug/47408
       # Can't hurt to have this just in case
       Exclusion      = /lib/udev/devices/

Only if you are also using the logcheck package, create /etc/logcheck/ignore.d.server/fcheck.local:

       # Ignore fcheck rebuild notices
       # Note that this should be one single line:
       ^\w{3} [ :0-9]{11} \w+ fcheck: “INFO: Rebuild of the fcheck database /var/lib/fcheck/fcheck\.dbf begun \
 for \w+ using config file /etc/fcheck/fcheck\.cfg”

Logcheck is a simple yet great idea, an almost set-it-and-forget-it way to monitor your server logs for problems of all kinds. You create three pattern (grep regex) lists:

• Known bad stuff
• Looks bad but isn’t
• Known good stuff

Logcheck periodically checks various syslog (or other) log files and picks up where it left off the last time. During each run it takes the new messages and looks for “known bad” things but first removes stuff that “looks bad but isn’t” and saves the messages as “this is known to be bad.” Then it rewinds, removes the known bad it just collected, removes the “known good” and stuff that “looks bad but isn’t” and saves whatever is left as “unknown.” Then it emails you the results.

Over time, as you tune your files, you end up only being alerted to known bad or new (not yet classified) stuff. Brilliant. I even did a (cheesy) Windows port of it.

Originally written by Marcus J. Ranum and Fred Avolio as frequentcheck.sh for the TIS Gauntlet firewall toolkit, it was adapted by Craig Rowland and applied to system logs. It spent some time as logsentry as part of Psionic’s Abacus/Sentry tools until they were bought by Cisco and the tools moved to SourceForge. The version in Debian is a re-write which was then inherited by Ubuntu.

But the best about the Debian/Ubuntu implementation is that almost all of the patterns you need are already Just There™. I usually only have to add a handful to work around odd things I’m doing or minor bugs. See the example at the bottom.

If you run a server you should be using fcheck and logcheck. And probably tmpreaper, etckeeper and maybe monit too. Articles about all these tools will be published soon, stay tuned!

As drawbacks, it should be noted that it may require some tuning, especially on a workstation or newer distro versions, and that may not be scalable for a lot of servers.

Is also worth mentioning that there are a variety of commercial and Managed Security Monitoring solutions that will scale and provide more information about events, but none are this easy.

Availability

The logcheck package is available in Debian since at least etch, and in Ubuntu since at least Dapper. See also the logcheck-database package.

Sample configuration

/etc/logcheck/ignore.d.server/LOCAL.ignore (lines wrapped for readability)

# /usr/sbin/logcheck automatically removes blank lines and comments.
# See 'man run-ports' for file name restrictions.

# For testing, create a sample log file and:
# su -s /bin/bash -c "/usr/sbin/logcheck -tsol sample" logcheck
# e.g.: su -s /bin/bash -c "/usr/sbin/logcheck -tsol /tmp/mylog" logcheck

# # DHCP Client lease renewals
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient: New
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ dhclient: DHCP(REQUEST|ACK)
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ NetworkManager:   DHCP daemon state
is now 3 \(renew\) for  interface

# # NTP, usually: 4001/0001
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ntpd\[[0-9]+\]: kernel time sync status
change [0-9]+

# # Syslog restarts (morning or all)
# ^\w{3} [ 0-9]{2} 07:[45][:0-9]{4} [._[:alnum:]-]+ syslogd
1\.5\.0#[0-9]ubuntu[0-9]: restart\.
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ syslogd 1.5.0#[0-9]ubuntu[0-9]: restart\.

# # fcheck
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ fcheck: “INFO: Rebuild of the fcheck
database  /var/lib/fcheck/fcheck\.dbf begun for [._[:alnum:]-]+ using config
file /etc/fcheck/fcheck\.cfg”

# # lm-sensors (normal)
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: \[[0-9. ]+\] CPU[01]:
Temperature/speed normal
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: \[[0-9. ]+\] Machine check events
logged

# # Wireless
# ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ NetworkManager:   \(eth1\):
supplicant connection state:

Article submitted by JP Vossen. DebADay needs you more than ever! Please submit good articles about software you like!

Nullmailer is a minimal MTA (Mail Transport Agent) that provides mail delivery services to programs (cron jobs, system integrity checkers, log inspectors, etc.) in a host that otherwise does not require a full MTA like Exim or Postfix. Do not confuse an MTA with programs like Evolution or Thunderbird which are MUAs (Mail User Agent): programs that offer an interface to a human to write email.

Nullmailer is one of those packages that create a “well duh” moment when you find out about it. Normally, hosts with no MTA can’t send mail, which turns out to be a Bad Thing in terms of finding out when things like cron jobs break, or for monitoring logs or files. So you go and install a minimal system, then wonder why it’s being so quiet. Well, no MTA, no email. But Exim, Postfix or another full MTA is overkill and might be tedious to maintain. What you really need is just a basic MTA to send messages to the real mail server.

That’s nullmailer.

The package will prompt for your remote mail server and create /etc/nullmailer/remotes, where you can also specify authentication details. You probably also want to create /etc/nullmailer/adminaddr to receive in one mail account all mail destined to your local host. Each file is a oneliner that contains pretty much what you’d expect:

$ cat /etc/nullmailer/adminaddr
I_get_roots_mail@example.com

$ cat /etc/nullmailer/remotes
mail.example.com

There are also several other files that may be used by nullmailer: /etc/nullmailer/defaultdomain and /etc/nullmailer/defaulthost in case you don’t already have /etc/mailname. For a complete list of control files, see the nullmailer(7) man page. Detailed information can be found in the man pages for each part of nullmailer: nullmailer-queue(8), nullmailer-inject(1), and nullmailer-send(8).

Pros:

• Simple.
• Just Works.
• Avoids the configuration, maintenance, memory footprint, and larger attack surface of a full MTA.

Cons:

• Configuration is scattered about in multiple one-line files instead of just a trivial config file.
• Documentation is a also bit scattered.
• The package might be a little more helpful by asking more questions when it’s installed (e.g. prompting for root’s mail recipient).
• Doesn’t provide the -bs switch, so it’s not LSB compatible.
• Gets very chatty in your log files when it can’t connect to the remote mail server.

Other alternatives:

• ssmtp - extremely simple MTA to get mail off the system to a mail hub
• http://linuxmafia.com/faq/Mail/nullmailers.html
• http://www.davidgrant.ca/ssmtp_vs_postfix_no_contest

Nullmailer has been available in Debian at least since Etch, and in Ubuntu Universe since Dapper.

Oops, this article was supposed to go live on Sunday, my bad.

Article submitted by Paul Wise. DebADay needs you more than ever! Please submit good articles about software you like!

Chromium B.S.U. is a top down fast paced high action scrolling space shooter. In this game you are the captain of the cargo ship Chromium B.S.U., and responsible for delivering supplies to the troops on the front line. Your ship has a small fleet of robotic fighters which you control from the relative safety of the Chromium vessel.

You control the robotic fighters with your mouse and repel wave after wave of different kinds of enemy ships. Launch Chromium B.S.U. from the Applications / Games / Arcade menu and start a new game. You will soon be sending volleys of weapon fire toward the enemy ships while protecting yourself with super shields, waiting for powerups to get closer or dodging fire from the larger enemy ships at the end of each level:

If you keep getting killed, quitcher whinin’, you ninny! It’s supposed to be hard! Seriously, Chromium B.S.U. is intended to be a 15 minute adrenaline rush/mental cleanser. Frequent doses of explosions can be very therapeutic. There is always kamikaze attacks or the BIG RED BUTTON if you get into particularly nasty trouble.

The chromium package is in Debian since lenny and Ubuntu since dapper, but it has been recently renamed to chromium-bsu. Chromium B.S.U. is an old favourite of the Linux gaming community that has been neglected until recently. The project is still looking for developers, especially to help move it off obsolete libs like libglpng and fix the rest of the bugs.

The chromium package has been available .

The chromium-bsu package has been available .

Article submitted by Paul Wise. DebADay needs you more than ever! Please submit good articles about software you like!

iotop is a console application for monitoring the I/O usage of processes on your system. It is especially handy for answering the question “Grrr, sloooowness, why is my disk churning so much?”

Just type iotop in your terminal and you will get a regularly updated list of processes and the amount of I/O they are currently using: reads and writesin bytes per second, and percentage of time spent swapping and waiting for I/O.

iotop is related to top and vmstat. In top you see a display of CPU and memory usage but not I/O. The vmstat utility shows it, but its just a stream of one-line reports instead of a dynamic display and doesn’t show the information in a per-process way.

Note that iotop needs the CONFIG_TASK_DELAY_ACCT and CONFIG_TASK_IO_ACCOUNTING options enabled in the kernel; in Debian stock kernels, that’s already the case.

iotop is available in Debian since Lenny and in Ubuntu (universe) since Intrepid.