Understanding the Automatons, Part Two11/21/2001
In the last article, we started looking at the scripts that are run by
periodic program. Let's finish looking at the remaining scripts in
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,
YES and keep an eye on your
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.
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
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
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
# 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
man security is a good place to start. For additional
resources, the following URLs also have general security information:
Let's take a quick look at the checks that are run as part of the daily security output:
Also in FreeBSD Basics:
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.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.
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.todayfor 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.
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
Pages: 1, 2