There are fewer settings but it is important to pay attention to all of them and understand what they are trying to communicate.
Sample Security Run Output
Checking setuid files and devices:
Checking negative group permissions:
Checking for uids of 0:
root 0
toor 0
Checking for passwordless accounts:
Checking login.conf permissions:
Checking for ports with mismatched checksums:
Hostname login failures:
Mar 25 17:51:41 Hostname sshd[33490]: Invalid user admin from 31.199.3.187
Mar 25 17:51:41 Hostname sshd[33490]: input_userauth_request: invalid user admin [preauth]
Mar 25 17:51:45 Hostname sshd[33496]: Invalid user db2fenc1 from 31.199.3.187
Mar 25 17:51:45 Hostname sshd[33496]: input_userauth_request: invalid user db2fenc1 [preauth]
Mar 25 17:51:47 Hostname sshd[33498]: Invalid user oracle from 31.199.3.187
Mar 25 17:51:47 Hostname sshd[33498]: input_userauth_request: invalid user oracle [preauth]
Mar 25 17:51:50 Hostname sshd[33502]: Invalid user git from 31.199.3.187
Mar 25 17:51:50 Hostname sshd[33502]: input_userauth_request: invalid user git [preauth]
Mar 25 17:52:04 Hostname sshd[33516]: Invalid user aaron from 31.199.3.187
Mar 25 17:52:04 Hostname sshd[33516]: input_userauth_request: invalid user aaron [preauth]
Mar 25 17:52:05 Hostname sshd[33519]: Invalid user gt05 from 31.199.3.187
Mar 25 17:54:42 Hostname sshd[33707]: input_userauth_request: invalid user oracle [preauth]
...
Mar 25 19:04:00 Hostname sshd[33953]: reverse mapping checking getaddrinfo for 92.30.65.218.broad.xy.jx.dynamic.163data.com.cn [218.65.30.92] failed - POSSIBLE BREAK-IN ATTEMPT! [preauth]
Mar 25 19:04:00 Hostname sshd[33953]: reverse mapping checking getaddrinfo for 92.30.65.218.broad.xy.jx.dynamic.163data.com.cn [218.65.30.92] failed - POSSIBLE BREAK-IN ATTEMPT!
Hostname refused connections:
Checking for packages with security vulnerabilities:
Database fetched: Wed Mar 25 03:12:53 EDT 2015
Checking setuid files and devices
Most days this should be a blank section. The very first time this script runs, it will contain a list of all the files on the system that have the setuid bit enabled. Subsequent runs will only show changes between runs. Operating system upgrades and some 3rd party software may change (usually add) setuid files or devices. This means you will only have one notification of the change.
The setuid permission is a special UNIX permission which says that the program (file) should be run as the owning user, not the user that actually ran the application. This is how FreeBSD (and UNIX systems in general) provide for temporary escalated privileges to ordinary users.
Unexpected changes need to be investigated. Abuse of setuid permissions is still one of the most common methods for internal users to gain unauthorized access to the root account and compromise systems.
You will see a sub-section with the heading, Hostname setuid diffs, when there are changes in setuid permissions.
Checking negative group permissions
There should never be negative group permissions on files or directories. This section should always be blank.
Negative group permissions means that 'other' users (users not in same group as the file/directory) have more permissions than 'group' users.
Naive system administrators have been known to use this tactic in an attempt to let one group of users read files that are created by a different group of users. The problem is that when file access permissions are checked, only the user's active group is checked. Any user in more than one group can change their active group and no longer be considered a 'group' user of the file. This makes a very fragile security model that is too easy to break.
Filesystem ACLs were created to provide the sort of functionality that an administrator might want in situations where negative groups are considered. Use filesystem ACLs instead.
Hostname changes in mounted filesystems
When the mounted filesystems change between security runs, a section that identifies the differences will be included. If no changes are made, this section does not show up.Administrators do have cause to make changes to mounted filesystems at times but malicious users may try to introduce new filesystems as a step to gaining unauthorized access to a server. Unexpected filesystem changes should be reviewed to determine the cause.
Checking for uids of 0
By default there are two accounts with UID 0 on FreeBSD. One is the well-known "root" account. The other is the "toor" account. Any other accounts that show up in this looks need to be looked at very carefully to understand not only where they came from but why.UID 0, regardless of the name associated with it, is the super-user account on UNIX and UNIX-like operating systems (including FreeBSD). The name is traditionally "root". The only thing that makes the account a super-user account is that it has UID 0.
It is perfectly fine to have more than one account with the same UID on FreeBSD although it is very rare to do so with anything other than UID 0.
The "toor" account is included with the base system to allow the system administrator to change the user shell for interactive sessions where full super-user authority is required. The root user shell should not be changed because so many automated tasks need to run as root and rely on the user-shell being the bourn shell that is included with the base system.
Some environments choose to remove the "toor" account from FreeBSD because it violates their internal security policy.
Checking for passwordless accounts
This provides a list of all local accounts that have a blank password set. This is distinct from having no password at all; which would prevent password login from working. No account should ever be created with a blank password.Checking login.conf permissions
This checks to ensure that the permission on the /etc/login.conf file have not changed from the default. Anything in this section indicates corrective action needs to be taken.The /etc/login.conf file defines system level permissions for users. Changes to this file will change system level access permission for one or more users. Attacks on login.conf are a common way to gain unauthorized administrative privileges or introduce vulnerabilities to a system. Only the root user should have read and write permission to this file (group and other should have read-only).
Checking for ports with mismatched checksums
This provides a list of entries in the ports tree (starting at /usr/ports) that have invalid checksums when compared to the default checksums. Anything showing up here should be considered a problem that needs to be addressed.The ports subsystem is another alternative to the package subsystem (discussed in a previous post). The main difference is that the ports subsystem provides source code and the system administrator must compile the source before installing the software. The ports subsystem includes all the functionality needed to easily compile and install on the local system.
Hostname kernel log messages
This is an extract of all kernel generated messages in /var/log/messages since the last run. It is usually blank.When a system is booted (or rebooted) there will be some kernel messages generated. Also when there are errors in the kernel, there will be generated. This can include problems identified by low level hardware drives.
Any kernel messages that are not associated with a system boot/reboot should be reviewed and understood because they could be an early indication of hardware problems.
Some messages from the boot/reboot process could also indicates problems. It is worthwhile becoming familiar with any kernel messages that show up.
Hostname login failures
This is a list of all login failures on the system. On servers it would be empty unless an administrator made a typing error. On systems that support end-users there will usually be a few mistyped passwords every day (depending on the end-user population). On Internet facing servers with login support there are bound to be many entries every day as the result of (hopefully failed) unauthorized login attempts.Every mistyped password would be included for most system login mechanisms (including console login, PAM, ssh, and x11). The included sample (above) shows a snippet of what is generated when an ssh server is exposed to the Internet. This happened less than an hour after the ssh server was made accessible.
The example was truncated to keep it reasonable. There were actually 58 separate attempts to connect over a period of 13 minutes. This would have been done by a simple script that just tries a bunch of different passwords.
The bottom section shows a different sort of attempt to break in. It was probably more sophisticated than the first since it gave up immediately.
Hostname refused connections
Provides a list of TCP refused connections. Internally this should be empty. If not, something may be misconfigured in your network. For Internet facing servers, it is yet another indication of the common attacks (such as port scans). Little can be done about the Internet side. It is a good reminder of the importance of firewalls.Checking for packages with security vulnerabilities
Most days this will only include the date and time that the package database was update (which is done as part of this process). It may also contain a list of packages installed on your system that have known security vuilnerabilities. That indicates it is time to upgrade the identified packages.
Simply put: it is time to upgrade anything that shows up in this section as soon as you can. Especially on servers that are exposed to the Internet.
Conclusion
The security report offers a lot of valuable information. Some sections will contain a lot of detail for which there is no action to be taken. Other sections give warning signs but only once. It is far too easy to miss the important parts of the security report due to the overwhelming amount of detail provided. The security report is much better than no report at all (which is what you get with most operating systems). but the security report is not a good substitute for a proper security monitoring solution, even on small installations.
