Chapter 9. Linux- and Mac OS X–Based Analysis
This chapter covers the following exam topics:
Now that we have covered Microsoft Windows, it’s time to move on to Linux and Mac OS X. The focus in this chapter will be to understand how things work inside a UNIX environment. Learning how the UNIX environment functions will not only improve your technical skills but can also help you build a strategy for securing UNIX-based systems. You won’t be expected to know every detail about the Linux or Mac OS X environments, so having an understanding of the topics covered in this chapter should be sufficient for the SECFND exam.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz helps you identify your strengths and deficiencies in this chapter’s topics. The ten-question quiz, derived from the major sections in the “Foundation Topics” portion of the chapter, helps you determine how to spend your limited study time. You can find the answers in Appendix A Answers to the “Do I Know This Already?” Quizzes and Q&A Questions.
Table 9-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.
1. Which process type occurs when a parent process is terminated and the remaining child process is permitted to continue on its own?
a. Zombie process
b. Orphan process
c. Rogue process
d. Parent process
2. A zombie process occurs when which of the following happens?
a. A process holds its associated memory and resources but is released from the entry table.
b. A process continues to run on its own.
c. A process holds on to associated memory but releases resources.
d. A process releases the associated memory and resources but remains in the entry table.
3. What is the best explanation of a fork (system call) in UNIX?
a. When a process is split into multiple processes
b. When a parent process creates a child process
c. When a process is restarted from the last run state
d. When a running process returns to its original value
4. Which of the following shows giving permissions to the group owners for read and execute, giving file owner permission for read, write, and execute, and giving all others permissions for execute?
a. -rwx-rx-x
b. -rx-rwx-x
c. -rx-x-rwx
d. -rwx-rwx-x
5. Which is a correct explanation of daemon permissions?
a. Daemons run at root-level access.
b. Daemons run at super user–level access.
c. Daemons run as the init process.
d. Daemons run at different privileges, which are provided by their parent process.
6. Which of the following is not true about symlinks?
a. A symlink will cause a system error if the file it points to is removed.
b. Showing the contents of a symlink will display the contents of what it points to.
c. An orphan symlink occurs when the link a symlink points to doesn’t exist.
d. A symlink is a reference to a file or directory.
7. What is a daemon?
a. A program that manages the system’s motherboard
b. A program that runs other programs
c. A computer program that runs as a background process rather than being under direct control of an interactive user
d. The only program that runs in the background of a UNIX system
8. Which priority level of logging will be sent if the priority level is err?
a. err
b. err, warning, notice, info, debug, none
c. err, alert, emerg
d. err, crit, alert, emerg
9. Which of the following is an example of a facility?
a. marker
b. server
c. system
d. mail
10. Which security technology would be best for detecting a pivot attack?
a. Virtual private network (VPN)
b. Host-based antivirus
c. NetFlow solution looking for anomalies within the network
d. Application layer firewalls
Foundation Topics
Processes
As defined in the last chapter on Microsoft Windows, a process is a running instance of a program. How a process works in Linux and OS X is different and will be the focus of this chapter. The two methods for starting a process are starting it in the foreground and starting it in the background. You can see all the processes in UNIX by using the command ps () in a terminal window, also known as a shell. What follows ps provides details of what type of processes should be displayed. For example, a would show all processes for all users, u would display the process’s owner, and x would show processes not attached to a terminal. Figure 9-1 shows running the ps aux command on a Kali Linux installation. Notice that the aux command displays the processes, users, and owners.
Running a process in the foreground means you can’t do anything else in that shell while the process is running. Running the process in the background (using the ampersand &) tells UNIX to allow you to do other tasks within the shell as the process is running. Here is an example of running the program “cisco” as a background process:
#The program cisco will execute in the background
./cisco &
The following types of processes can run in UNIX:
Child process
Init process
Orphan process
Zombie process
Daemon process
We will now cover each of these briefly and go into a little more detail on the daemon process in a later section of this chapter because it has a few important concepts to cover for the SECFND exam. A process starts in the ready state and eventually executes when it is moved to the running state; this is known as process scheduling. Process scheduling is critical to keeping the CPU busy, delivering minimum response time for all programs, and keeping the system from crashing. This is achieved by using rules for moving processes in and out of the CPU using two different scheduling tactics. The first is non-preemptive scheduling, which is when executing processes gives up CPU voluntarily. The other is preemptive scheduling, which is when the OS decides that another process has a greater importance and preempts the currently running process.
Processes can have a parent/child relationship. A child process is a process created by some other process during runtime. Typically, a child process is created to execute a task within an existing process, also known as a parent process. A parent process uses a fork system call to create child processes. Usually a shell is created that becomes the parent, and the child process executes inside of it. We examine the fork command in the next section of this chapter. All processes in UNIX have a parent except for the init process, which will be covered shortly. Each process is given an integer identifier, known as a process identifier (PID). The process schedule is giving a PID value of 0 and typically termed as sched. In Figure 9-1, notice the PIDs assigned to the various processes.
The init process is the first process during the boot sequence, meaning the init process does not have a parent process. The init process is another name for the schedule process; hence, its PID value is 1. Figure 9-2 shows a diagram of the init PID creating parent processes, which in turn are creating child processes.
In this diagram, a child process may receive some shared resources from its associated parent, depending on how the system is implemented. Best practice is to put restrictions in place to avoid the child process from consuming more resources than the parent process can provide, which would cause bad things to happen. The parent process can use the Wait system call, which pauses the process until the Wait returns. The parent can also issue a Run system call, thus permitting the child to continue without waiting (basically making it a background task). A process can terminate if the system sees one of the following situations:
The system doesn’t have the resources to provide.
The parent task doesn’t need the task completed that is assigned to the child process.
The parent stops, meaning the associated child doesn’t have a parent process anymore. This can cause the system either to terminate the child process or to let it run as an orphan process.
The Exit or Kill command is issued.
When the process ends, any associated system resources are freed up and any open files are flushed and closed. If a parent is waiting for a child process to terminate, a termination status and the time of execution are returned to the parent process. The same data can be returned to the init process if the process that ended was an orphan process.
An orphan process results when a parent process is terminated and the child process is permitted to continue on its own. Orphan processes become the child process of the init process; but they are still labeled as orphan processes because their parent no longer exists. The time between when the child process ends and the status information is returned to the parent, the process continues to be recorded as an entry in the process table. During this state, the terminated process becomes a zombie process, releasing the associated memory and resources but remaining in the entry table. Usually the parent will receive a SIGCHILD signal, letting it know the child process has terminated. The parent can then issue a Wait call that grabs the exit status of the terminated process and removes the process from the entry table. A zombie process can become a problem if the parent is killed off and not permitted to remove the zombie from the entry table. Zombie processes that linger around eventually become inherited by the init process and are terminated.
The list that follows highlights the key process concepts:
The two methods for starting a process are starting it in the foreground and starting it in the background.
The different types of processes in UNIX are the child process, init process, orphan process, zombie process, and daemon process.
All processes in UNIX have a parent, except for the init process, which has a PID of 1.
An orphan process results when a parent process is terminated and the child process is permitted to continue on its own.
A zombie process is a process that releases its associated memory and resources but remains in the entry table.
Forks
A fork is when a parent creates a child process, or simply the act of creating a process. This means the fork command returns a process ID (PID). The parent and child processes run in separate memory spaces, and the child is a copy of the parent. The entire virtual space of the parent is replicated in the child process, including all the memory space. The child also inherits copies of the parent’s set of open file descriptors, open message queue descriptors, and open directory streams.
To verify which process is the parent and which is the child, you can issue the fork command. The result of the fork command can be one of the following.
A negative value (-1), indicating the child process was not created, followed by the number of the last error (or errno). One of the following could be the error:
EAGAIN: The system limited the number of threads for various reasons.
EAGAIN Fork: Failed to allocate the necessary kernel structures due to low memory.
ENOMEN: Attempt to create a child process in a PID whose init process has terminated.
ENOSYS Fork: The process is not supported on the platform.
ERESTARTNOINTR: The system call was interrupted by a signal and will be restarted.
A zero, indicating a new child process was created.
A positive value, indicating the PID of the child to its parent.
After the fork, the child and parent processes not only run the same program, but they resume execution as though both had made the system call. They will then inspect the system call’s return value to determine their status and act accordingly. One thing that can impact a process’s status is what permissions it has within its space to operate. We take a deeper look at UNIX permissions in the next section.
The list that follows highlights the key fork concepts:
A fork is when a parent creates a child process.
The fork command returns a process ID (PID).
The entire virtual space of the parent is replicated in the child process, including all the memory space.
Permissions
UNIX and Mac OS X are different from other operating systems in that they are both multitasking and multiuser systems. Multitasking involves the forking concepts previously covered, and multiuser means more than one user can be operating the system at the same time. Yes, a laptop may only have one keyboard; however, that doesn’t mean others can’t connect to it over a network and open a shell to operate the computer. This functionality has always been included in the UNIX operating system since the times of large mainframe computers. However, this functionality can also be a bad thing if a malicious user gets shell access to the system, even when the system owner is logged in and doing daily tasks.
To ensure the practicality of offering multiuser access, it is important to have controls put in place for each user. These controls are known as file permissions. File permissions assign access rights for the owner of the file, members of the group of related users, and everybody else. Permissions can be granted to read a file, write to a file, and execute a file (meaning run the file as a program). You can see the permission settings of a file by typing the command ls -l (filename). This will return a long string of information, starting with the file’s permission (such as -rw-r---r--). Example 9-1 demonstrates displaying the file permissions for a file called ninjatune1.png.
Example 9-1 Displaying File Permissions for a File
JOMUNIZ-M-91SU:documents jomuniz$ ls –l ninjatune1.png
-rwxrwxrwx@ 1 jomuniz staff 90277 Oct 15 2013 ninjatune1.png
JOMUNIZ-M-91SU:documents jomuniz$
The first part of this output shows read, write, and execution rights, represented with the rwx statements. These are defined as follows:
read (r): Reading, opening, viewing, and copying the file are permitted.
write (w): Writing, changing, deleting, and saving the file are permitted.
execution (x): Executing and invoking the file is permitted. This includes permitting directories to have search access.
The second part of the output shows the file owner. The file owner in this example is “jomuniz,” one of your friendly authors. The next item is the owner’s group. In this example, we have a group called “staff.” The last part is what everybody else has access to. This example shows all three parts—user jomuniz, group staff, and everybody else all have read, write, and execution rights to this file. Now let’s look at Example 9-2, where we view the file rights for the bash program located in the /bin directory.
Example 9-2 Displaying File Rights for a Program
JOMUNIZ-M-91SU:/ jomuniz$ ls –l /bin/bash
-rxr-xr-x 1 root wheel 628496 Jan 13 2016 /bin/bash
JOMUNIZ-M-91SU:/ jomuniz$
The first part of this output shows the user right settings for the file. The user is currently “root” and the group is “wheel.” Everybody else has the access right to just execute this file. To break down the permissions further, let’s look at the permissions statement -rwx-xr-x, broken down as follows:
The opening - means a regular file. A d would indicate a directory.
Next, rwx means read, write, and execution rights for the owner of the file.
-xr means read and execution rights for the group owning the file.
Finally, -x means execution rights for everybody else.
File permissions for a file or directory can be modified using the chmod command, which you use to specify the settings and the file or files you wish to modify (for example, using the command chmod 700 the_file). The number 700 represents a series of bits, which translates to the associated rwx privileges you find with the ls command. You can also add a -v to get a verbose response to the command (as in chmod –v 700 the_file). The math for permissions works like this:
Read (r) = 4
Write (w) = 2
Execution (x) = 1
Giving access to everybody would mean R=4 + W=2 + X=1, for a grand total of 7. That means the first digit of 7 represents the file owner having access to everything. The digits for the group and everybody else are 0, meaning no access. Therefore, the number 700 means the owner has access to everything while the group and everybody else have no access. The prior example used –rwx-xr-r. Here, the first number would again be 7, while xr would be 5 (R=4 + X=1) to represent read and execution access rights for the group. The last part is just read access, so that means R=4 for everybody else. This all translates –rwx-xr-r to the number 754. Therefore, to change the file permission to this, you would use the command chmod 754 the_file.
Table 9-2 represents a complete list of permission values. Note that this table would be used to compute the desired rights for the file owner, group, and everybody else, making it a three-digit number.
You can also be specific about whom you are granting rights to or removing rights from using the characters a (all), u (user), g (group), and o (others). For example, you can use the command chmod g=r the_file to change the group to read-only for the file. Another example would be the command chmod a+x the_file, which adds the execution privilege for all users. This means = gives a specific group a permission, - removes a permission, and + adds a permission. To see a few comparisons of using the complete chmod command verses the shortened equivalent, check out the following list comparing the different approaches covered:
All the previous chmod examples assume you are in the directory where the file is located. You may want to change files in another directory, which can be expressed in the chmod command as well. This is done by specifying the file path as directory/file.txt (verses just file.txt) so that the command knows where to look for the file.
NOTE
You need at least the minimal file permission execution (x) to access a directory. Without any permissions, you won’t be able to access the directory.
File permissions in UNIX take a top-down approach, meaning that denying access for a directory will automatically include all subdirectories and files. For example, suppose you have the directory FILE_D with the permission drwxr-xr-x and a subdirectory SUBFILE_D with the permission drwxr-xr-x. Now suppose you want to deny read, write, and execution access for the group and everybody else without impacting the owner of FILE_D. In this case, you would use the command chmod go-rwx FILE_D, meaning –rwx removes access from FILE_D for the group and other users. This would also impact the subdirectory SUBFILE_D, even though SUBFILE_D’s permissions are drwxr-xr-x, meaning groups and other users within SUBFILE would not have access to anything due to the parent fold FILE_D denying access, which flows down to SUBFILE.
The same concept works for whomever you assign rights to, meaning that if you give rights to the group and others in SUBFILE_D, this would not give the same rights to FILE_D. This is why sometimes an admin to a folder may give access to a file but not the folder it is contained in and find people with access rights to the file can’t reach the file due to not being able to open the folder.
Another concept to touch upon is the group, which is the set of permissions for one or more users who are grouped together. When an account is created, the user is assigned to a group. For example, you might have a group called employees for all employees and another group called administrators for network operations. This allows you to grant the same level of permissions to an entire group verses having to do so for each user. Users can be members of one or more groups. You can view which groups a user is a member of and their user ID by using the command id. Figure 9-3 shows an example of user jomuniz, with the user ID of 501, being part of various groups with their associated numbers.
If you own a file and are a member of more than one group, you can modify the group “ownership” of that file using the chgrp command. For example, the command chgrp staff file.txt would give the group “staff” permissions to file.txt. Note that this does not impact the individual ownership of the file. Ownership can only be changed by the file owner. The chgrp command just gives group permissions to the file, as in the previous example of giving the group “staff” access. To change the owner of the file, you can use the command chown. For example, you could use chown Bob file.txt to give Bob ownership of the file.
Sometimes changing the group or owner will require super user privileges, which provide the highest access level and should only be used for specific reasons, such as performing administrative tasks. Most UNIX distributions offer the command su (substitute user), which can give super user rights for short tasks. Doing this will require you to enter the super user’s password. If successful, you will end up with a shell with super user rights. Typing exit will return you to your previous user permissions level.
Distributions such as Ubuntu offer the command sudo, which gives super user rights on an as-needed basis. Typically this is to execute a specific command, meaning you would type sudo whatever_command to execute the command with super user rights. The difference between su and sudo is that after entering sudo, you will be prompted for the user’s password rather than the super user’s password.
NOTE
Administrators should always proceed with caution when permitting super user and root-level permissions. All processes, including background daemons, should be limited to only the permissions required to successfully execute their purpose. Giving processes too much access could be a serious risk in case of a compromised process, which an attacker could use to gain full system access.
The list that follows highlights the key permissions concepts:
File permissions assign access rights for the owner of the file, members of a group of related users, and everybody else.
The command chmod modifies file permissions for a file or directory.
Read (r) = 4, Write (w) = 2, Execute (x) = 1.
A group is the set of permissions for one or more users grouped together.
You can modify the group “ownership” of a file using the chgrp command.
To change the owner of a file, you can use the command chown.
File permissions in UNIX take a top-down approach, meaning denying access for a directory will automatically include all subdirectories and files.
Super user privileges provide the highest access level and should only be used for specific reasons, such as performing administrative tasks.
All processes, including background daemons, should be limited to only the permissions necessary to successfully accomplish their purpose.
Symlinks
The next topic we’ll cover is how to link files together. A symlink (short for symbolic link, and sometimes called a “soft link”) is any file that contains a reference to another file or directory in an absolute or relative path that affects pathname resolution. In short, a symlink contains the name for another file but doesn’t contain actual data. From a command viewpoint, a symlink looks like a standard file, but when it’s referenced, everything points to whatever the symlink is aimed at.
Let’s look at an example of creating a file. Example 9-3 shows the echo command putting Vanilla Ice’s lyric into a file called file1. You can see the contents of the file by using the cat command. After file1 is created, we create a symlink using the command ln –s /tmp/file.1 /tmp/file.2 pointing file.2 to file.1. Finally, to verify both files, we use the command ls –al /tmp/file* to show both files.
Example 9-3 Displaying File Rights for a Program
[JOMUNIZ-M-91SU:~ jomuniz$ echo "Stop collaborate and listen" > /tmp/file.1
[JOMUNIZ-M-91SU:~ jomuniz$ cat /tmp/file.1
Stop collaborate and listen
[JOMUNIZ-M-91SU:~ jomuniz$ ln –s /tmp/file.1 /tmp/file.2
[JOMUNIZ-M-91SU:~ jomuniz$ ls –al /tmp/file*
-rw-r--r-- 1 jomuniz wheel 28 Jul 26 11:08 /tmp/file.1
Lrwxr-xr-x 1 jomuniz wheel 11 Jul 26 11:09 /tmp/file.2 -> /tmp/file.1
JOMUNIZ-M-91SU:~ jomuniz$
Notice in Example 9-3 how the permissions for file.2 start with a “l,” thus confirming the file is a symbolic link. The end of the statement also shows file.2 is referencing file.1 via the “->” symbol between the paths. To validate this, you can issue the cat command to view the contents of file.2, which are the contents from file.1, as shown in Example 9-4.
Example 9-4 Displaying File Contents
[JOMUNIZ-M-91SU:~ jomuniz$ cat /tmp/file.2
Stop collaborate and listen
JOMUNIZ-M-91SU:~ jomuniz$
Because a symlink is just a reference, removing the symlink file doesn’t impact the file it references. This means removing file.2 won’t have any impact on file.1. If file.1 is removed, it will cause an orphan symlink, meaning a symlink pointing to nothing because the file it references doesn’t exist anymore. For example, let’s change file.1 to file.3 using the mv command. Example 9-5 shows this action. It then shows that there are now two files, file.2 symlinked to file.1 (even though file1 doesn’t exist) and file.3. Example 9-5 also shows the results of attempting to view file.2 using the cat command. It returns “no such file or directory” because file.2 is now an orphan symlink. This shows how symlinks are interpreted at runtime, meaning that if we move file.3 back to file.1, file.2 would once again show Vanilla Ice’s lyrics. One last key point is that unlike a hard link, a symlink can exist even if what it points to does not exist.
Example 9-5 Displaying File Contents
[JOMUNIZ-M-91SU:~ jomuniz$ mv /tmp/file.1 /tmp/file.3
[JOMUNIZ-M-91SU:~ jomuniz$ ls –al /tmp/file*
Lrwxr-xr-x 1 jomuniz wheel 11 Jul 26 11:09 /tmp/file.2 -> /tmp/file.1
-rw-r--r-- 1 jomuniz wheel 28 Jul 26 11:08 /tmp/file.3
[JOMUNIZ-M-91SU:~ jomuniz$ cat /tmp/file.2
Cat: /tmp/file.2: No such file or directory
JOMUNIZ-M-91SU:~ jomuniz$
The list that follows highlights the key symlink concepts:
A symlink is any file that contains a reference to another file or directory.
A symlink is just a reference. Removing the symlink file doesn’t impact the file it references.
An orphan symlink is a symlink pointing to nothing because the file it references doesn’t exist anymore.
A symlink is interpreted at runtime and can exist even if what it points to does not.
Daemons
We opened this chapter by explaining how processes can run in the foreground and background. When a process runs in the background, it is known as a daemon. Daemons are not controlled by the active user; instead they run unobtrusively in the background, waiting to be activated by the occurrence of a specific event or condition. UNIX systems usually have numerous daemons running to accommodate requests for services from other computers and responding to other programs and hardware activity. Daemon can be triggered by many things, such as a specific time, event, file being viewed, and so on. Essentially, daemons listen for specific things to trigger their response.
When initiated, a daemon, like any other process, will have an associated process identification number (PID). Daemons are system processes, so their parent is usually the init process, which has a PID value of 1 (but this is not always the case). Daemon processes are created by the system using the fork command, thus forming the process hierarchy covered previously in this chapter.
The following list shows some common daemons found in UNIX. You may notice that most daemon programs end with “d” to indicate they are a daemon.
xinetd: The TCP/IP super server listening to ports assigned to processes listed in inetd.conf or einetd.config
corond: Runs scheduled tasks
lpd: Used for laser printing
rlogind: Used for remote login
rshd: Used for remote command execution
telnetd: Used for telnet
Not all daemons are started automatically. Just like with other processes, daemons such as binlogd, mysqld, and apache can be set to not start unless the user or some event triggers them. This also means daemons, like any other program, can be terminated, restarted, and have their status evaluated. It is common for many daemons to be started at system boot; however, some are child processes that are launched based on a specific event. This all depends on the version of the system you are running.
The list that follows highlights the key daemon concepts:
Daemons are programs that run in the background.
From a permissions viewpoint, daemon’s are typically created by the init process.
A daemon’s permissions level can vary depending on what is provided to it. Daemons should not always have super user–level access.
Daemons are not controlled by the active user; instead, they run unobtrusively in the background, waiting to be activated by a specific event or condition.
Not all daemons are started automatically.
Children of the init process can be terminated and restarted.
UNIX-Based Syslog
UNIX-based systems have very flexible logging capabilities, enabling the user to record just about anything. The most common form of logging is the general-purpose logging facility called syslog. Most programs send logging information to syslog. Syslog is typically a daemon found under the /var/log directory. You can see the logs by typing cd /var/log followed by ls to view all the logs. Make sure you know the location of these files.
The facility describes the application or process that submits the log message. Table 9-3 provides examples of facilities. Not all of these are available in every version of UNIX.
All messages are not treated the same. A priority is used to indicate the level of importance of a message. Table 9-4 summarizes the priority levels.
For the SECFND exam, you should know the different general log types. Transaction logs record all transactions that occur. For example, a database transaction log would log any modifications to the database. Alert logs record errors such as a startup, shutdown, space errors, and so on. Session logs track changes made on managed hosts during a web-based system manager session. Logging occurs each time an administrator uses web-based system management to make a change on a host. Threat logs trigger when an action matches one of the security profiles attached to a security rule. It is important to distinguish what type of log would go where for an event scenario. An example would be knowing that a system crash would be an alert log and that a malicious attack would be a threat log. Actions such as logging are triggered by selectors.
Selectors monitor for one or more facility and level combinations and, when triggered, perform some action. When a specific priority level is specified, the system will track everything at that level as well as anything higher. For example, if you use crit, you will see messages associated with crit, alert, and emerg. This is why enabling debug is extremely chatty because you are essentially seeing all messages.
Actions are the results from a selector triggering on a match. Actions can write to the log file, echo the message to the console or to other devices so users can read it, send a message to another syslog server, and perform other actions.
The configuration file /etc/syslog.conf controls what syslogd does with the log entries it receives. This file contains one line per action; the syntax for every line is a selector field followed by an action field. The syntax used for the selector field is facility.level, which is designed to match log messages from a facility at a level value or higher. Also, you can add an optional comparison flag before the level to specify more precisely what is being logged. The syslog.conf file can use multiple selector fields for the same action, separated by semicolons. The special character * sets a check to match everything. The action field points out where the logs should be sent. An example would be if something within the selector is triggered, sending a file to a remote host. Figure 9-4 shows a sample syslog.conf file.
Looking at this example, you can see that the first line shows that if the selector matches any message with a level of err or higher (kern.warning, auth.notice, and mail.crit), it will take the action of sending these logs to the /dev/console location. The fifth line down shows that if the selector sees all messages from mail at a level of info or above, it will take the action of having logs sent to /var/log/maillog. The syslog.conf file will vary from system to system, but this example should give you an idea of how the file is designed to work.
One common area of concern is managing logs. Many companies have log-retention requirements, such as storing logs for up to a year. Log files can grow very quickly, depending on how selectors and actions are set up, making it challenging to accommodate storage requirements as well as actually using the log information. Log management tools such as newsyslog attempt to mitigate this by periodically rotating and compressing log files. Newsyslog is not a system daemon and by default runs every hour. Figure 9-5 shows an example of a newsyslog file.
The output showcases the filename, file owner, permissions, when to rotate the file, optional flags, and programs to signal when a log is rotated. Looking at line 2 of Figure 9-5, you can see that the file to be rotated is /var/log/all.log. There is the option to show the owner and group, but this example just shows blank space. The mode field sets up the permissions on the log file whereas the count field depicts how many rotated log files should be kept. Basically this means line 2 shows the permission 600 and a file count of 7. The size field is used to trigger when the log should be rotated. This occurs when either the log’s size is larger than the size field or when time has passed a marker in the field settings. Line 2 shows an asterisk (*), which tells newsyslog to ignore this field. The flag field gives extra instructions, such as how to compress the rotated file.
Logging can become extremely challenging to manage as more systems are generating logs. This is when centralized log management becomes the key to successful log management. Tons of centralized logging solutions are available, including free and open source as well as fancier enterprise offerings.
The general concept is the centralized log management solution must be capable of accepting logging information from the source sending the logs. Popular log management offerings have the ability to accept logs from a variety of systems; however, sometimes a system will generate logs in a unique format that requires tuning of how the message is read. Adjusting messages to an acceptable format for a centralized management system is known as “creating a custom parser.” It is recommended that you identify all systems that potentially will generate log messages and validate whether they produce logging in a universally accepted format such as syslog. Logging has been around for a while, so in most cases, any relatively current centralized logging solution should be capable of accepting most common logging formats.
The list that follows highlights the key UNIX syslog concepts:
The most common form of logging is the general-purpose logging facility called syslog.
The default location of logs in UNIX is the /var/log directory.
The facility describes the application or process that submits the log message.
A priority is used to indicate the level of importance of the message.
Transaction logs record all transactions that occur.
Session logs track changes made on managed hosts during a web-based system manager session.
Alert logs record errors such as a startup, shutdown, space errors, and so on.
Threat logs trigger when an action matches one of the security profiles attached to a security rule.
Selectors monitor for one or more facility and level combinations and, when triggered, perform some action.
Actions are the result of a selector triggering on a match.
The configuration file /etc/syslog.conf controls what syslogd does with the log entries it receives.
Newsyslog attempts to mitigate log management by periodically rotating and compressing log files.
Apache Access Logs
One important aspect of logging is monitoring the activity and performance of a server. With regard to UNIX, Apache is a very popular option and therefore a topic on the SECFND exam. The focus for this section is on Apache logging, which is important for maintaining the health and security of such systems.
The Apache HTTP server provides a variety of different mechanisms for logging everything that happens on the server. Logging can include everything from an initial request to the final resolution of a connection, including any errors that may have happened during the process. Also, many third-party options complement the native logging capabilities; these include PHP scripts, CGI programs, and other event-sending applications.
In regard to errors, Apache will send diagnostic information and record any errors it encounters to the log file set by the ErrorLog directive. This is the first place you should go when troubleshooting any issues with starting or operating the server. You can use the command cat, grep, or any other UNIX text utility for this purpose. Basically, this file can answer what went wrong and how to fix it. The file is typically error_log on UNIX systems and error.log on OS X.
Another important log file is the access log controlled by the CustomLog directive. Apache servers record all incoming requests and all requests to this file. Basically, this file contains information about what pages people are viewing, the success status of a request, and how long the request took to respond.
Usually tracking is broken down into three parts: access, agent, and referrer. Respectively, these track access to the website, the browser being used to access the site, and the referring URL the site’s visitor arrives from. It is very common to leverage Apache’s combined log format, which combines all three of these logs into one log file. Most third-party software prefer a single log containing this information. The combined format typically looks like this:
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" combined
LogFormat starts the line by telling Apache that you define a log file type, which is combined. The following list explains the commands called by this file:
%h: Logs the remote host
%l: Remote log name
%t: The date and time of the request
%r: The request to the website
%s: The status of the request
%b: Bytes sent for the request
%i: Items sent in the HTML header
The full list of Apache configuration codes for custom logs can be found at http://httpd.apache.org/docs/2.0/mod/mod_log_config.html.
Like with any other UNIX system, Apache logging will most likely generate a lot of data very quickly, making it necessary to have proper rotation of logs. You have many options, including auto-removing files that are too big and archiving older copies of data for reference. In a crisis situation, you may manually move the files; however, a soft restart of Apache is required before it can begin to use the new logs for new connections. An automated method would use a program such as Logrotate. Logrotate can enforce parameters that you set such as certain date, size, and so on.
The list that follows highlights the key Apache access log concepts:
Apache sends diagnostic information and records any errors it encounters to the ErrorLog log.
Apache servers record all incoming requests and all requests to the access log file.
The combined log format lists the access, agent, and referrer fields.
Exam Preparation Tasks
Review All Key Topics
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 9-5 lists these key topics and the page numbers on which each is found.
Complete Tables and Lists from Memory
Print a copy of Appendix B, “Memory Tables,” (found on the book website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the website, includes completed tables and lists to check your work.
Define Key Terms
Define the following key terms from this chapter, and check your answers in the glossary:
init process
symlink
priority
session log
Q&A
The answers to these questions appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Questions.” For more practice with exam format questions, use the exam engine on the website.
1. Which of the following statements is not true about a daemon process?
a. A daemon is a process that runs in the background.
b. A daemon’s parent process is typically the init process.
c. Daemons are controlled by the active user.
d. Not all daemons are automatically started.
2. Apache will send diagnostic information and record any errors that it encounters to which of the following?
a. ErrorLog
b. Dump.txt
c. syslog
d. Accesslog
3. Which of the following explains the file permissions for -rwx-rwx-x?
a. The owner has read, write, and execution permissions; the group has read, write and execution permissions; everybody else has read permission.
b. The owner has read and execution permissions; the group has read, write, and execution permissions; everybody else has write permission.
c. The owner has read, write, and execution permissions; the group has read, write, and execution permissions; everybody else has execution permission.
d. The group has read, write, and execution permissions; the owner has read, write, and execution permissions; everybody else has execution permission.
4. Which is a true statement about a symlink?
a. Deleting the symlink file deletes the file it references.
b. Moving a file referenced by a symlink will cause a system error.
c. Symlinks are the same as pointers.
d. A symlink is also known as a soft link.
5. Which log type would be used for recording changes in a SQL database?
a. Transaction logs
b. Alert logs
c. Session logs
d. Threat logs
6. Which process has a PID of 1?
a. Daemon
b. Parent
c. Child
d. Init
7. When issuing the command ls -l (filename), what is the correct order of user permissions?
a. group, owner, everybody else
b. everybody else, group, owner
c. owner, everybody else, group
d. owner, group, everybody else
8. Which command can change the file owner?
a. file
b. owner
c. chown
d. chmod
9. Which of the following explains Linux daemon permissions?
a. Daemons get permissions from the init process.
b. Daemons get permissions from a parent process.
c. Daemons are always the highest level of permissions.
d. Daemons and the init are the same thing.
10. Where is the UNIX log located?
a. /var/log
b. /dev/console
c. /etc/log
d. /config/log
References and Further Reading
http://help.unc.edu/help/how-to-use-unix-and-linux-file-permissions/
https://www.freebsd.org/doc/handbook/configtuning-syslog.html