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