Understanding the Automatons, Part Two

In the last article, we started looking at the scripts that are run by the periodic program. Let's finish looking at the remaining scripts in today's article.

We left off at the accounting script. System accounting is off by default, so disable this script if you don't plan on enabling system accounting. If you're not sure what system accounting does, man sa gives a list of what statistics will be gathered. If you decide to enable system accounting, consider changing daily_accounting_compress to YES and keep an eye on your disk-space usage.

# 310.accounting
daily_accounting_enable="YES"   # Rotate acct files
daily_accounting_compress="NO"  # Gzip rotated files
daily_accounting_flags=-q       # Flags to /usr/sbin/sa
daily_accounting_save=3         # How many files to save

This is another script that deals with rdist, so if you're not maintaining identical copies of files over multiple hosts, disable it.

# 320.distfile
daily_distfile_enable="YES"  # Run rdist daily

You should disable the news script; even if you are running a news server, it should have a built-in mechanism to handle expired news articles.

# 330.news
daily_news_expire_enable="YES" # Run news.expire

Now we get to some UUCP stuff. There are three scripts that deal with UUCP, so I'll lump them together and talk about them at the same time. Scripts 340 and 410 are found in the daily section and script 300 is found in the weekly section:

# 340.uucp
daily_uuclean_enable="YES"       # Run uuclean.daily

# 410.status-uucp
daily_status_uucp_enable="YES"   # Check uucp status

# 300.uucp
weekly_uucp_enable="YES"         # Clean uucp weekly

Unfortunately, the UUCP program has been prone to several vulnerabilities over the years, and just happens to be the subject of the latest security advisory, FreeBSD-SA-01:62. It is a very good idea to disable the three scripts that deal with UUCP. Furthermore, if you don't have a need to use the tip or cu utilities, you don't even need UUCP on your system. Follow the directions in section IV of the advisory to see which binaries to remove and how to prevent rebuilding these binaries when you remake your system.

# 400.status-disks
daily_status_disks_enable="YES"           # Check disk status
daily_status_disks_df_flags="-k -t nonfs # df(1) flags for check

You'll probably want to keep the disk status script enabled, and you should check its output on a daily basis to ensure you are not running out of disk space. Note that you can change the flag line to include the switches you prefer to pass to the df utility. Since I don't use NFS and I like to keep track of my free inodes and see the output in human readable format, my line looks like this:

daily_status_disks_df_flags="-h -i  # df(1) flags for check

Which gives me this output:

instead of the default output, which would look like this:

The first line in the network status script runs the netstat utility; if you don't want the script to resolve IP addresses to network names, change the second line to NO. It's up to you to decide if the output of this script is useful enough to you to warrant keeping it enabled.

# 420.status-network
daily_status_network_enable="YES"  # Check network status
daily_status_network_usedns="YES"  # DNS lookups are ok

The output of the next script depends on whether or not the rwho daemon is running. If it is not, it will show the uptime of your local system; if it is, it will show the uptime for each machine in your LAN.

# 430.status-rwho
daily_status_rwho_enable="YES"  # Check system status

The next script runs mailq, the output of which will let you know if there is any mail stuck in the queue.

# 440.status-mailq
daily_status_mailq_enable="YES"    # Check mail status
daily_status_mailq_shorten="NO"    # Shorten output

The security script is probably the most important script run by periodic, and its output should be checked on a daily basis. You'll note that the output is mailed separately from the rest of the daily output scripts, and can be mailed to a different user (the default user is root). Also, keep the inline line set at NO; if you set it to YES, it will be sent to the terminal instead of to a user. You do want a trusted user to read this output on a daily basis, in case further investigation is required.

# 450.status-security
daily_status_security_enable="YES"   # Security check
daily_status_security_inline="NO"    # Run inline ?
daily_status_security_output="root"  # user or /file
daily_status_security_noamd="NO"     # Don't check amd mounts
daily_status_security_nomfs="NO"     # Don't check mfs mounts

The security check runs a script called /etc/security. This script checks for well-known vulnerabilities, meaning that anything in its output should be looked at to ensure your system hasn't been compromised. If you are new to security and aren't familiar with all of the terms mentioned in the output, man security is a good place to start. For additional resources, the following URLs also have general security information:

• http://people.freebsd.org/~jkb/howto.html
• http://www.cert.org/tech_tips/usc20_full.html

Let's take a quick look at the checks that are run as part of the daily security output:

• setuid files

  Setuid files are one of the oldest known vulnerabilities in Unix systems. Fortunately, your FreeBSD system keeps a list of which files are setuid in /var/log/setuid.today and /var/log/setuid.yesterday. The first thing the security check does each night is to see if there are any differences between these two files; that is, it can notify you if a new setuid file shows up on your system. If it does, you want to be aware of it.

• uids of 0

  By default, the only users on your system that have a UID of 0 are root and toor. An UID of 0 means that that user has root access to your FreeBSD system, so you should be VERY suspicious is a new user shows up under this section of the output.

• Passwordless accounts

  We all know that user accounts without passwords are a bad thing. The daily security output will notify you if any passwordless accounts show up so you can rectify the situation.

• Packets denied by ipfw

  Remember how we took a look at ipfw's logs in IPFW Logging? This portion of the security script will check /var/log/ipfw.today for you and give you the stats on how many packets were rejected for each of your logged deny rules.

• ipfw rules that have reached the log limit

  This portion of the script will tell you which IPFW rules reached their logging limits.

• ipv6 packets denied by ip6fw

• ipv6 rules which reached ip6fw's log limit

• Kernel log messages

  This portion of the script will show the contents of dmesg.today, meaning it will show the system messages.

• Login failures

• tcp_wrapper warning messages

  If you've configured tcp wrappers, any warning messages will be recorded for you. If you don't know how to configure this program, see Securing BSD Daemons.

Leaving the security script, let's move on to the next script, which will show you if any mail was rejected.

# 460.status-mail-rejects
daily_status_mail_rejects_enable="YES"  # Check mail rejects
daily_status_mail_rejects_logs=3        # How many logs to check

The status-named script can be disabled if you are not running a DNS server. If you are running a DNS server, check the output of this script, as it will let you know if your DNS server denied any zone transfers. A zone transfer request from a machine that is not one of your secondary DNS servers may indicate that someone is trying to gather information about your network. For more information on setting up a secure DNS server, you can read the security chapter of DNS and Bind, 4th Edition.

# 470.status-named
daily_status_named_enable="YES"
daily_status_named_usedns="YES"  # DNS lookups are ok

The next script ensures that sendmail's queue is processed at least once per day. You don't have to run this script, as by default sendmail will check its queue every 30 minutes for undeliverable mail and will try to resend any messages at that point.

# 500.queuerun
daily_queuerun_enable="YES"   # Run mail queue

That's it for the built-in daily scripts; let's move on to the weekly scripts. You'll note that you're once again given the option to specify where to send the weekly output, and again, the default is to email it to root.

# Weekly options

# These options are used by periodic(8) itself to 
# determine what to do with the output of the sub-programs
# that are run, and where to send that output.  $weekly_output
# might be set to /var/log/weekly.log if you wish to log the 
# weekly output and have the files rotated by newsyslog(8)
#
weekly_output="root"        # user or /file
weekly_show_success="YES"   # scripts returning 0
weekly_show_info="YES"      # scripts returning 1
weekly_show_badconfig="NO"  # scripts returning 2

The first script cleans out any kvm* files in /var/db. Since I don't have any of these files on my system, I've disabled this script.

# 120.clean-kvmdb
weekly_clean_kvmdb_enable="YES"   # Clean kvmdb weekly
weekly_clean_kvmdb_days=7         # If not accessed for
weekly_clean_kvmdb_verbose="YES"  # Mention files deleted

The next two scripts update the locate and whatis databases; if you've ever heard your hard drive churning around 4:00 on a Saturday morning, this is the reason why. Since locate and apropos are two of my favorite commands, I keep these scripts enabled.

# 310.locate
weekly_locate_enable="YES"   # Update locate weekly

# 320.whatis
weekly_whatis_enable="YES"   # Update whatis weekly

The next script is disabled by default; if you have lots of disk space and read a lot of man pages, you may find that enabling this script speeds up using the man utility.

# 330.catman
weekly_catman_enable="NO"       # Preformat man pages

The next script is also disabled. Enable it if you want to be aware of any files on your system that don't have a valid owner or group.

# 340.noid
weekly_noid_enable="NO"     # Find unowned files
weekly_noid_dirs="/"        # Look here

The last built-in weekly script is interesting, and may be worth enabling if you like to keep up-to-date with the ports tree. It will compare your already installed ports with /usr/ports/INDEX and make a list of which ports have a newer version number and should be updated.

# 400.status-pkg
weekly_status_pkg_enable="NO"   # Find out-of-date pkgs

There is only one built-in monthly script and you are again given the option of where to send its output.

# Monthly options

# These options are used by periodic(8) itself to 
# determine what to do with the output of the sub-programs
# that are run, and where to send that output.  $monthly_output
# might be set to /var/log/monthly.log if you
# wish to log the monthly output and have the files rotated 
# by newsyslog(8)
#
monthly_output="root"            # user or /file
monthly_show_success="YES"       # scripts returning 0
monthly_show_info="YES"          # scripts returning 1
monthly_show_badconfig="NO"      # scripts returning 2

# 200.accounting
monthly_accounting_enable="YES"  # Login accounting

This script will show the accounting statistics gathered by the ac command. If these statistics aren't useful to you, disable this script. We took a look at the ac command in Monitoring Unix Logins.

I hope this article helped to de-mystify the scripts that came with your FreeBSD system. Until next time, happy BSDing.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Copyright © 2007 O'Reilly Media, Inc.