6
PROCESS MANAGEMENT

At any given time, a Linux system typically has hundreds, or sometimes even thousands, of processes running simultaneously. A process is simply a program that’s running and using resources. Examples of a process include a terminal, web server, any running commands, any databases, the GUI interface, and much more. Any good Linux administrator—and particularly a hacker—needs to understand how to manage their processes to optimize their systems. For example, once a hacker takes control of a target system, they might want to find and stop a certain process, like an antivirus application or firewall. To do so, the hacker would first need to know how to find the process. The hacker might also want to set a scanning script to run periodically to find vulnerable systems, so we’ll also look at how to schedule such a script.

In this chapter, you’ll learn to manage those processes. First, you’ll learn to view and find processes and how to discover which processes are using the most resources. Then, you’ll learn to manage processes by running them in the background, prioritizing them, and killing them if necessary (no blood involved). Finally, you’ll learn to schedule processes to run on specified days and dates and at specific times.

Viewing Processes

In most cases, the first step in managing processes is to view what processes are running on your system. The primary tool for viewing processes—and one of the Linux administrator’s best friends—is the ps command. Run it in your command line to see what processes are active:

kali >ps
PID     TTY      TIME       CMD
39659   pts/0    00:00:01   bash
39665   pts/0    00:00:00   ps

The Linux kernel, the inner core of the operating system that controls nearly everything, assigns a unique process ID (PID) to each process sequentially, as the processes are created. When working with these processes in Linux, you often need to specify their PIDs, so it is far more important to note the PID of the process than the name of the process.

Alone, the ps command doesn’t really provide you with much information. Running the ps command without any options lists the processes started (said to be invoked) by the currently logged-in user (in our case, root) and what processes are running on that terminal. Here, it simply says that the bash shell is open and running and that we ran the ps command. We want and need far more information than that, particularly on those processes run by other users and by the system in the background. Without this information, we know very little of what is actually taking place on our system.

Running the ps command with the options aux will show all processes running on the system for all users, as shown in Listing 6-1. Note that you don’t prefix these options with a dash (-) and that everything is in lowercase; because Linux is case-sensitive, using uppercase options would give you significantly different results.

kali >ps aux
USER   PID   %CPU   %MEM    VSZ    RSS TTY    STAT START   TIME   COMMAND
root    1    0.0   0.4    202540   6396 ?    Ss   Apr24    0:46   /sbin/init
root    2    0.0   0.0         0      0 ?    S    Apr24    0:00   [kthreadd]
root    3    0.0   0.0         0      0 ?    S    Apr24    0:26   [ksoftirqd/0]
--snip--
root 39706   0.0   0.2   36096   3204 pts/0    R+ 15:05   0:00    ps aux

Listing 6-1: Using the aux options to see processes for all users

As you can see, this command now lists so many processes, they likely run off the bottom of your screen. The first process is init, listed in the final column, and the last process is the command we ran to display, ps aux. Many of the details (PID, %CPU, TIME, COMMAND, and so on) may be different on your system but should have the same format. For our purposes, here are the most important columns in this output:

USER   The user who invoked the process

PID   The process ID

%CPU   The percent of CPU this process is using

%MEM   The percent of memory this process is using

COMMAND   The name of the command that started the process

In general, to perform any action on a process, we must specify its PID. Let’s see how to use this identifier to our advantage.

Filtering by Process Name

When we inquire about or perform an action on processes, we usually don’t want all of the processes displayed on the screen. It’s simply a problem of too much information. Most often, we want to find information on a single process. To do so, we can use the filtering command grep, which I introduced in Chapter 1.

To demonstrate, we’ll use the Metasploit exploitation framework, the most widely used exploitation framework and nearly every hacker’s good friend. This comes installed on your Kali system, so start Metasploit with the following:

kali >msfconsole

Once the exploitation framework has been started, let’s see whether we can find it in the list of processes. Metasploit has now taken over this terminal, so open another terminal. Now, use the ps aux command and then pipe it (|) to grep looking for the string msfconsole, as in Listing 6-2.

kali >ps aux | grep msfconsole
1:36 ruby /usr/bin/msfconsole
root 39892   0.0   0.0   4304   940   pts/2 S+   15:18   0:00 grep msfconsole

Listing 6-2: Filtering a ps search to find a particular process

From the filtered output in this listing, you should see all the processes that match the term msfconsole. Here, you see the msfconsole program itself from /usr/bin/msfconsole, and then you should see the grep command you used to look for msfconsole. Notice that the output did not include the column header list from ps. Since the keyword, msfconsole, is not in the header, it is not displayed. Even so, the results are displayed in the same format.

From this, you can learn some important information. If, for example, you need to know how many resources Metasploit is using, you can consult the third column (the CPU column), to see that it’s using 35.1 percent of your CPU, and consult the fourth column to see that it’s using 15.2 percent of your system memory. That’s quite a bit. It’s a demanding beast!

Finding the Greediest Processes with top

When you enter the ps command, the processes are displayed in the order they were started, and since the kernel assigns PIDs in the order they have started, what you see are processes ordered by PID number.

In many cases, we want to know which processes are using the most resources. This is where the top command comes in handy because it displays the processes ordered by resources used, starting with the largest. Unlike the ps command, which gives us a one-time snapshot of the processes, top refreshes the list dynamically—by default, every 3 seconds. You can watch and monitor those resource-hungry processes, as shown in Listing 6-3.

kali >top
top - 15:31:17 up 2 days, 6:50, 4 users, load average: 0.00, 0.04, 0.09
Tasks: 176 total, 1 running, 175 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 0.7 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.0 hi 0.0 si 0.0
MiB Mem : 1491220 total,   64848 free, 488272 used, 938100 buff/cache
MiB Swap : 1046524 total, 1044356 free, 2168 used. 784476 avail MEM

PID   USER   PR   NI   VIRT    RES     SHR     S   %CPU  %MEM   TIME+    COMMAND
39759 root   20   0   893180   247232  11488   S   0.7   16.6   1:47.88   ruby
39859 root   20   0   27308    16796   14272   S   0.3   1.2    1:47.88   postgres
39933 root   20   0   293936   61500   29108   S   0.7   4.1    1:47.88   Xorg
--snip--

Listing 6-3: Finding the greediest processes with top

System administrators often keep top running in a terminal to monitor use of process resources. As a hacker, you may want to do the same, especially if you have multiple tasks running on your system. While you have top running, pressing the H or ? key will bring up a list of interactive commands, and pressing Q will quit top. You’ll use top again soon to manage your processes in “Changing Process Priority with nice” on page 65 and “Killing Processes” on page 66.

Managing Processes

Hackers often need to multiprocess, and an operating system like Kali is ideal for this. The hacker may have a port scanner running while running a vulnerability scanner and an exploit simultaneously. This requires that the hacker manage these processes efficiently to best use system resources and complete the task. In this section, I’ll show you how to manage multiple processes.

Changing Process Priority with nice

You don’t often hear the word nice used in the context of hackers, but here you will. The nice command is used to influence the priority of a process to the kernel. As you saw when we ran the ps command, numerous processes run on the system at once, and all of them are contending for the available resources. The kernel will have final say over the priority of a process, but you can use nice to suggest that a process should be elevated in priority.

The idea behind the use of the term nice is that, when you use it, you’re determining how “nice” you’ll be to other users: if your process is using most of the system resources, you aren’t being very nice.

The values for nice range from −20 to +19, with zero being the default value (see Figure 6-1). A high nice value translates to a low priority, and a low nice value translates to a high priority (when you’re not being so nice to other users and processes). When a process is started, it inherits the nice value of its parent process. The owner of the process can lower the priority of the process but cannot increase its priority. Of course, the superuser or root user can arbitrarily set the nice value to whatever they please.

Figure 6-1: Niceness priority values

When you start a process, you can set the priority level with the nice command and then alter the priority after the process has started running with the renice command. The syntax for these two commands is slightly different and can be confusing. The nice command requires that you increment the nice value, whereas the renice command wants an absolute value for niceness. Let’s look at an example to demonstrate this.

Setting the Priority When Starting a Process

For demonstration purposes, let’s assume we have a process named slowprocess that’s located at /bin/slowprocess. If we wanted it to speed up its completion, we could start the process with the nice command:

kali >nice   -n -10 /bin/slowprocess

This command would increment the nice value by -10, increasing its priority and allocating it more resources.

On the other hand, if we want to be nice to our fellow users and processes and give slowprocess a lower priority, we could increment its nice value positively by 10:

kali >nice -n 10 /bin/slowprocess

Give this a try on a process you have currently running and then run ps to see how it changes, if at all.

Changing the Priority of a Running Process with renice

The renice command takes absolute values between –20 and 19 and sets the priority to that particular level, rather than increasing or decreasing from the level at which it started. In addition, renice requires the PID of the process you are targeting rather than the name. So, if slowprocess is using an inordinate amount of resources on your system and you want to give it a lower priority, thus allowing other processes a higher priority and more resources, you could renice the slowprocess (which has a PID of 6996) and give it a much higher nice value, like so:

kali >renice 19 6996

As with nice, only the root user can renice a process to a negative value to give it higher priority, but any user can be nice and reduce priority with renice.

You can also use the top utility to change the nice value. With the top utility running, simply press the R key and then supply the PID and the nice value. Listing 6-4 shows the top utility running. When I press the R key and supply the PID and nice value, I get the following output:

  top - 21:36:56 up 21:41,   2 users, load average: 0.60, 0.22, 0.11
  Tasks: 128 total,   1 running, 127 sleeping, 0 stopped, 0 zombie
  %Cpu(s): 1.5 us, 0.7 sy, 0.0 ni, 96.7 id, 1.1 wa, 0.0 hi, 0.0 si, 0.0 st
  KiB Mem:   511864 total,   500780 used, 11084 free,   152308 buffers
  KiB Swap:   901116 total,   14444 used,   886672 free,   171376 cached
➊ PID to renice
  |
  PID    USER   PR   NI   VIRT   RES   SHR   S   %CPU  %MEM  TIME      COMMAND
  5451   root   20   0   1577m   19m   14m   S   5.3   3.9   42:46.26  0LLYDBG.EXE
  2766   root   20   0   55800   20m   5480  S   2.6   4.0   1:01.42   Xorg
  5456   root   20   0   6356    4272  1780  S   1.3   0.8   13:21.69  wineserver
  7      root   20   0   0       0     0     S   0.3   0.0   0:30.12   rcu_sched
  5762   root   20   0   174m    20m   17m   S   0.3   4.1   0:04.74   gnome-terminal

Listing 6-4: Changing a nice value when top is in use

When I press the R key, I’m asked for the PID ➊ with the text renice PID [value] to value. The output should then change to reflect the new priorities.

Killing Processes

At times, a process will consume way too many system resources, exhibit unusual behavior, or—at worst—freeze. A process that exhibits this type of behavior is often referred to as a rogue process. For you, probably the most problematic symptom will be wasted resources used by the rogue process that could be better allocated to useful processes.

When you identify a problematic process, you may want to stop it with the kill command. There are many different ways to kill a program, and each has its own kill number.

The kill command has 64 different kill signals, and each does something slightly different. Here, we focus on a few you will likely find most useful. The syntax for the kill command is kill-signal PID, where the signal switch is optional. If you don’t provide a signal flag, it defaults to SIGTERM. Table 6-1 lists the common kill signals

Table 6-1: Commonly Used Kill Signals

Signal name	Number for option	Description
SIGHUP	1	This is known as the Hangup (HUP) signal. It stops the designated process and restarts it with the same PID.
SIGINT	2	This is the Interrupt (INT) signal. It is a weak kill signal that isn’t guaranteed to work, but it works in most cases.
SIGQUIT	3	This is known as the core dump. It terminates the process and saves the process information in memory, and then it saves this information in the current working directory to a file named core. (The reasons for doing this are beyond the scope of this book.)
SIGTERM	15	This is the Termination (TERM) signal. It is the kill command’s default kill signal.
SIGKILL	9	This is the absolute kill signal. It forces the process to stop by sending the process’s resources to a special device, /dev/null.

Using the top command, you can identify which processes are using too many resources; often, those processes will be legitimate, but there may be malicious processes taking resources that you’ll want to kill.

If you just want to restart a process with the HUP signal, enter the -1 option with kill, like so:

kali >kill -1 6996

In the case of a rogue or a malicious process, you likely want to send the kill -9 signal, the absolute kill signal, to the process. This makes certain that the process is terminated.

kali >kill -9 6996

If you don’t know a process’s PID, you can use the killall command to kill the process. This command takes the name of the process, instead of the PID, as an argument.

For example, you could terminate a hypothetical rogueprocess like this:

kali >killall -9 rogueprocess

Finally, you can also terminate a process in the top command. Simply press the K key and then enter the PID of the offending process.

Running Processes in the Background

In Linux, whether you’re working from the command line or the GUI, you’re working within a shell. All commands that run are executed from within that shell, even if they run from the graphical interface. When you execute a command, the shell waits until the command is completed before offering another command prompt.

At times, you may want a process to run in the background, rather than having to wait for it to complete in that terminal. For instance, say we want to work on a script in a text editor and so have called our text editor (leafpad) by entering the following:

kali >leafpad newscript

In this case, the bash shell will open the leafpad text editor to create newscript. While we work in the text editor, the terminal is occupied with running the text editor. If we return to the terminal, we should see that it is running our text editor and that we have no new prompt to allow us to enter more commands.

We could, of course, open another terminal to run more commands, but a better option to save resources and screen real estate is to start the text editor running in the background. Running a process in the background simply means that it will continue to run without needing the terminal. In this way, the terminal is freed up for other duties.

To start the text editor in the background, just append an ampersand (&) to the end of the command, like so:

kali >leafpad newscript &

Now, when the text editor opens, the terminal returns a new command prompt so we can enter other commands on our system while also editing our newscript. This is effective for any process that may run for a significant length of time when you want use the terminal. As a hacker, you’ll find this useful for running multiple terminals with multiple tasks, to save resources and screen space.

You can also move a process to the background using the bg command followed by the PID of the process. If you don’t know the PID, you can use the ps command to find it.

Moving a Process to the Foreground

If you want to move a process running in the background to the foreground, you can use the fg (foreground) command. The fg command requires the PID of the process you want to return to the foreground, as shown next.

kali >fg 1234

If you don’t know the PID, you can use the ps command to find it.

Scheduling Processes

Both Linux system administrators and hackers often need to schedule processes to run at a particular time of day. A system administrator might want to schedule a system backup to run every Saturday night at 2 AM, for example. A hacker might want to set a script to run to perform reconnaissance on a regular basis, finding open ports or vulnerabilities. In Linux, you can accomplish this in at least two ways: with at and crond.

The at command is used to set up the daemon—a background process—atd, which is useful for scheduling a job to run once at some point in the future. The crond daemon is more suited for scheduling tasks to occur every day, week, or month, and we’ll cover this in detail in Chapter 16.

We use the at daemon to schedule the execution of a command or set of commands in the future. The syntax is simply the at command followed by the time to execute the process. The time argument can be provided in various formats. Table 6-2 contains the most common at time formats.

Table 6-2: Time Formats Accepted by the at Command

Time format	Meaning
at 7:20pm	Scheduled to run at 7:20 PM on the current day
at 7:20pm June 25	Scheduled to run at 7:20 PM on June 25
at noon	Scheduled to run at noon on the current day
at noon June 25	Scheduled to run at noon on June 25
at tomorrow	Scheduled to run tomorrow
at now + 20 minutes	Scheduled to run in 20 minutes from the current time
at now + 10 hours	Scheduled to run in 10 hours from the current time
at now + 5 days	Scheduled to run in five days from the current date
at now + 3 weeks	Scheduled to run in three weeks from the current date
at 7:20pm 06/25/2019	Scheduled to run at 7:20 PM on June 25, 2019

When you enter the at daemon with the specified time, at goes into interactive mode and you are greeted with an at> prompt. Here is where you enter the command you want executed at the specified time:

kali >at 7:20am
at >/root/myscanningscript

This code snippet will schedule myscanningscript to execute today at 7:20 AM. When you want to stop entering commands, hit CTRL-D.

Summary

Managing processes in Linux is a key skill for every Linux user and hacker. You must be able to view, find, kill, prioritize, and schedule processes to manage your Linux instance optimally. A hacker often will need to find processes on the target they want to kill, such as the antivirus software or a firewall. They will also need to manage multiple processes in an attack and prioritize them.